- 數(shù)據(jù)庫維護
-
執(zhí)行計劃是數(shù)據(jù)庫根據(jù)SQL語句和相關表的統(tǒng)計信息作出的一個查詢方案,這個方案是由查詢優(yōu)化器自動分析產(chǎn)生的,比如一條SQL語句如果用來從一個 10萬條記錄的表中查1條記錄,那查詢優(yōu)化器會選擇“索引查找”方式,如果該表進行了歸檔,當前只剩下5000條記錄了,那查詢優(yōu)化器就會改變方案,采用 “全表掃描”方式。
1、 首先要搞明白什么叫執(zhí)行計劃?
執(zhí)行計劃是數(shù)據(jù)庫根據(jù)SQL語句和相關表的統(tǒng)計信息作出的一個查詢方案,這個方案是由查詢優(yōu)化器自動分析產(chǎn)生的,比如一條SQL語句如果用來從一個 10萬條記錄的表中查1條記錄,那查詢優(yōu)化器會選擇“索引查找”方式,如果該表進行了歸檔,當前只剩下5000條記錄了,那查詢優(yōu)化器就會改變方案,采用 “全表掃描”方式。
可見,執(zhí)行計劃并不是固定的,它是“個性化的”。產(chǎn)生一個正確的“執(zhí)行計劃”有兩點很重要:
(1) SQL語句是否清晰地告訴查詢優(yōu)化器它想干什么?
(2) 查詢優(yōu)化器得到的數(shù)據(jù)庫統(tǒng)計信息是否是最新的、正確的?
2、 統(tǒng)一SQL語句的寫法
對于以下兩句SQL語句,程序員認為是相同的,數(shù)據(jù)庫查詢優(yōu)化器認為是不同的。
select*from dual
select*From dual
其實就是大小寫不同,查詢分析器就認為是兩句不同的SQL語句,必須進行兩次解析。生成2個執(zhí)行計劃。所以作為程序員,應該保證相同的查詢語句在任何地方都一致,多一個空格都不行!
3、 不要把SQL語句寫得太復雜
我經(jīng)常看到,從數(shù)據(jù)庫中捕捉到的一條SQL語句打印出來有2張A4紙這么長。一般來說這么復雜的語句通常都是有問題的。我拿著這2頁長的SQL語句去請教原作者,結果他說時間太長,他一時也看不懂了??上攵?,連原作者都有可能看糊涂的SQL語句,數(shù)據(jù)庫也一樣會看糊涂。
一般,將一個Select語句的結果作為子集,然后從該子集中再進行查詢,這種一層嵌套語句還是比較常見的,但是根據(jù)經(jīng)驗,超過3層嵌套,查詢優(yōu)化器就很容易給出錯誤的執(zhí)行計劃。因為它被繞暈了。像這種類似人工智能的東西,終究比人的分辨力要差些,如果人都看暈了,我可以保證數(shù)據(jù)庫也會暈的。
另外,執(zhí)行計劃是可以被重用的,越簡單的SQL語句被重用的可能性越高。而復雜的SQL語句只要有一個字符發(fā)生變化就必須重新解析,然后再把這一大堆垃圾塞在內(nèi)存里。可想而知,數(shù)據(jù)庫的效率會何等低下。
4、 使用“臨時表”暫存中間結果
簡化SQL語句的重要方法就是采用臨時表暫存中間結果,但是,臨時表的好處遠遠不止這些,將臨時結果暫存在臨時表,后面的查詢就在tempdb中了,這可以避免程序中多次掃描主表,也大大減少了程序執(zhí)行中“共享鎖”阻塞“更新鎖”,減少了阻塞,提高了并發(fā)性能。
5、 OLTP系統(tǒng)SQL語句必須采用綁定變量
select*from orderheader where changetime >'2010-10-20 00:00:01'
select*from orderheader where changetime >'2010-09-22 00:00:01'
以上兩句語句,查詢優(yōu)化器認為是不同的SQL語句,需要解析兩次。如果采用綁定變量
select*from orderheader where changetime >@chgtime
@chgtime變量可以傳入任何值,這樣大量的類似查詢可以重用該執(zhí)行計劃了,這可以大大降低數(shù)據(jù)庫解析SQL語句的負擔。一次解析,多次重用,是提高數(shù)據(jù)庫效率的原則。
6、 綁定變量窺測
事物都存在兩面性,綁定變量對大多數(shù)OLTP處理是適用的,但是也有例外。比如在where條件中的字段是“傾斜字段”的時候。
“傾斜字段”指該列中的絕大多數(shù)的值都是相同的,比如一張人口調(diào)查表,其中“民族”這列,90%以上都是漢族。那么如果一個SQL語句要查詢30歲的漢族人口有多少,那“民族”這列必然要被放在where條件中。這個時候如果采用綁定變量@nation會存在很大問題。
試想如果@nation傳入的第一個值是“漢族”,那整個執(zhí)行計劃必然會選擇表掃描。然后,第二個值傳入的是“布依族”,按理說“布依族”占的比例可能只有萬分之一,應該采用索引查找。但是,由于重用了第一次解析的“漢族”的那個執(zhí)行計劃,那么第二次也將采用表掃描方式。這個問題就是著名的“綁定變量窺測”,建議對于“傾斜字段”不要采用綁定變量。
7、 只在必要的情況下才使用begin tran
SQL Server中一句SQL語句默認就是一個事務,在該語句執(zhí)行完成后也是默認commit的。其實,這就是begin tran的一個最小化的形式,好比在每句語句開頭隱含了一個begin tran,結束時隱含了一個commit。
有些情況下,我們需要顯式聲明begin tran,比如做“插、刪、改”操作需要同時修改幾個表,要求要么幾個表都修改成功,要么都不成功。begin tran 可以起到這樣的作用,它可以把若干SQL語句套在一起執(zhí)行,最后再一起commit。好處是保證了數(shù)據(jù)的一致性,但任何事情都不是完美無缺的。Begin tran付出的代價是在提交之前,所有SQL語句鎖住的資源都不能釋放,直到commit掉。
可見,如果Begin tran套住的SQL語句太多,那數(shù)據(jù)庫的性能就糟糕了。在該大事務提交之前,必然會阻塞別的語句,造成block很多。
Begin tran使用的原則是,在保證數(shù)據(jù)一致性的前提下,begin tran 套住的SQL語句越少越好!有些情況下可以采用觸發(fā)器同步數(shù)據(jù),不一定要用begin tran。
8、 一些SQL查詢語句應加上nolock
在SQL語句中加nolock是提高SQL Server并發(fā)性能的重要手段,在oracle中并不需要這樣做,因為oracle的結構更為合理,有undo表空間保存“數(shù)據(jù)前影”,該數(shù)據(jù)如果在修改中還未commit,那么你讀到的是它修改之前的副本,該副本放在undo表空間中。這樣,oracle的讀、寫可以做到互不影響,這也是oracle 廣受稱贊的地方。SQL Server 的讀、寫是會相互阻塞的,為了提高并發(fā)性能,對于一些查詢,可以加上nolock,這樣讀的時候可以允許寫,但缺點是可能讀到未提交的臟數(shù)據(jù)。使用 nolock有3條原則。
(1) 查詢的結果用于“插、刪、改”的不能加nolock !
(2) 查詢的表屬于頻繁發(fā)生頁分裂的,慎用nolock !
(3) 使用臨時表一樣可以保存“數(shù)據(jù)前影”,起到類似oracle的undo表空間的功能,
能采用臨時表提高并發(fā)性能的,不要用nolock 。
9、 聚集索引沒有建在表的順序字段上,該表容易發(fā)生頁分裂
比如訂單表,有訂單編號orderid,也有客戶編號contactid,那么聚集索引應該加在哪個字段上呢?對于該表,訂單編號是順序添加的,如果在orderid上加聚集索引,新增的行都是添加在末尾,這樣不容易經(jīng)常產(chǎn)生頁分裂。然而,由于大多數(shù)查詢都是根據(jù)客戶編號來查的,因此,將聚集索引加在contactid上才有意義。而contactid對于訂單表而言,并非順序字段。
比如“張三”的“contactid”是001,那么“張三”的訂單信息必須都放在這張表的第一個數(shù)據(jù)頁上,如果今天“張三”新下了一個訂單,那該訂單信息不能放在表的最后一頁,而是第一頁!如果第一頁放滿了呢?很抱歉,該表所有數(shù)據(jù)都要往后移動為這條記錄騰地方。
SQL Server的索引和Oracle的索引是不同的,SQL Server的聚集索引實際上是對表按照聚集索引字段的順序進行了排序,相當于oracle的索引組織表。SQL Server的聚集索引就是表本身的一種組織形式,所以它的效率是非常高的。也正因為此,插入一條記錄,它的位置不是隨便放的,而是要按照順序放在該放的數(shù)據(jù)頁,如果那個數(shù)據(jù)頁沒有空間了,就引起了頁分裂。所以很顯然,聚集索引沒有建在表的順序字段上,該表容易發(fā)生頁分裂。
曾經(jīng)碰到過一個情況,一位哥們的某張表重建索引后,插入的效率大幅下降了。估計情況大概是這樣的。該表的聚集索引可能沒有建在表的順序字段上,該表經(jīng)常被歸檔,所以該表的數(shù)據(jù)是以一種稀疏狀態(tài)存在的。比如張三下過20張訂單,而最近3個月的訂單只有5張,歸檔策略是保留3個月數(shù)據(jù),那么張三過去的 15張訂單已經(jīng)被歸檔,留下15個空位,可以在insert發(fā)生時重新被利用。在這種情況下由于有空位可以利用,就不會發(fā)生頁分裂。但是查詢性能會比較低,因為查詢時必須掃描那些沒有數(shù)據(jù)的空位。
重建聚集索引后情況改變了,因為重建聚集索引就是把表中的數(shù)據(jù)重新排列一遍,原來的空位沒有了,而頁的填充率又很高,插入數(shù)據(jù)經(jīng)常要發(fā)生頁分裂,所以性能大幅下降。
對于聚集索引沒有建在順序字段上的表,是否要給與比較低的頁填充率?是否要避免重建聚集索引?是一個值得考慮的問題!
10、加nolock后查詢經(jīng)常發(fā)生頁分裂的表,容易產(chǎn)生跳讀或重復讀
加nolock后可以在“插、刪、改”的同時進行查詢,但是由于同時發(fā)生“插、刪、改”,在某些情況下,一旦該數(shù)據(jù)頁滿了,那么頁分裂不可避免,而此時nolock的查詢正在發(fā)生,比如在第100頁已經(jīng)讀過的記錄,可能會因為頁分裂而分到第101頁,這有可能使得nolock查詢在讀101頁時重復讀到該條數(shù)據(jù),產(chǎn)生“重復讀”。同理,如果在100頁上的數(shù)據(jù)還沒被讀到就分到99頁去了,那nolock查詢有可能會漏過該記錄,產(chǎn)生“跳讀”。
上面提到的哥們,在加了nolock后一些操作出現(xiàn)報錯,估計有可能因為nolock查詢產(chǎn)生了重復讀,2條相同的記錄去插入別的表,當然會發(fā)生主鍵沖突。
11、使用like進行模糊查詢時應注意
有的時候會需要進行一些模糊查詢比如
select*from contact where username like ‘%yue%’
關鍵詞%yue%,由于yue前面用到了“%”,因此該查詢必然走全表掃描,除非必要,否則不要在關鍵詞前加%,
12、數(shù)據(jù)類型的隱式轉換對查詢效率的影響
sql server2000的數(shù)據(jù)庫,我們的程序在提交sql語句的時候,沒有使用強類型提交這個字段的值,由sql server 2000自動轉換數(shù)據(jù)類型,會導致傳入的參數(shù)與主鍵字段類型不一致,這個時候sql server 2000可能就會使用全表掃描。Sql2005上沒有發(fā)現(xiàn)這種問題,但是還是應該注意一下。
13、SQL Server 表連接的三種方式
(1) Merge Join
(2) Nested Loop Join
(3) Hash Join
SQL Server 2000只有一種join方式——Nested Loop Join,如果A結果集較小,那就默認作為外表,A中每條記錄都要去B中掃描一遍,實際掃過的行數(shù)相當于A結果集行數(shù)x B結果集行數(shù)。所以如果兩個結果集都很大,那Join的結果很糟糕。
SQL Server 2005新增了Merge Join,如果A表和B表的連接字段正好是聚集索引所在字段,那么表的順序已經(jīng)排好,只要兩邊拼上去就行了,這種join的開銷相當于A表的結果集行數(shù)加上B表的結果集行數(shù),一個是加,一個是乘,可見merge join 的效果要比Nested Loop Join好多了。
如果連接的字段上沒有索引,那SQL2000的效率是相當?shù)偷?,而SQL2005提供了Hash join,相當于臨時給A,B表的結果集加上索引,因此SQL2005的效率比SQL2000有很大提高,我認為,這是一個重要的原因。
總結一下,在表連接時要注意以下幾點:
(1) 連接字段盡量選擇聚集索引所在的字段
(2) 仔細考慮where條件,盡量減小A、B表的結果集
(3) 如果很多join的連接字段都缺少索引,而你還在用SQL Server 2000,趕緊升級吧。