現(xiàn)在數(shù)據(jù)庫服務(wù)器的配置都很高，雖然通過大內(nèi)存、RAID技術(shù)解決了磁盤IO的瓶頸，但對(duì)于我們業(yè)務(wù)系統(tǒng)長(zhǎng)期運(yùn)行產(chǎn)生的海量數(shù)據(jù)來說對(duì)查詢優(yōu)化也是十分重要的。下面介紹幾種優(yōu)化方法：
1、數(shù)據(jù)轉(zhuǎn)儲(chǔ)和分區(qū)表：前者查詢起來麻煩，需要union兩個(gè)以上的表，轉(zhuǎn)儲(chǔ)時(shí)用刪除原表、插入歷史表的方法，可減少生產(chǎn)服務(wù)器的存儲(chǔ)空間（數(shù)量少查詢就快），用于處理極不常用的歷史數(shù)據(jù)；使用分區(qū)表時(shí)需要在查詢時(shí)指定分區(qū)表名，操作起來不靈活，但清除歷史數(shù)據(jù)的速度比較快，可以把一個(gè)分區(qū)表數(shù)據(jù)刪除，非常適合銷售流水之類的數(shù)據(jù)。
2、在同樣情況下表多次掃描慢于一次描，所以用exists、not exists代替in、not in，來減少掃描次數(shù)，并在寫關(guān)聯(lián)條件時(shí)盡量用索引字段。
3、join 快于left join 快于 full join。
4、在寫查詢時(shí)用“sp_help 表名”看下這個(gè)表有幾個(gè)索引，哪個(gè)索引最適合你，盡量把索引的第一個(gè)字段作為查詢的第一個(gè)條件，第二個(gè)字段作為查詢的第二個(gè)條件等。不要在索引字段上加函數(shù)，如：datediff(day,c_date,@日期)=0，如果c_date是這個(gè)表的索引字段，那么數(shù)據(jù)庫引擎不會(huì)選擇這個(gè)索引，可以改成這樣c_date>=@日期 and c_date<dateadd(day,1,@日期)，得出的結(jié)果是一樣的，但效率會(huì)差幾十倍（取決于數(shù)據(jù)量，越大越明顯），為什么會(huì)慢呢？ 即使c_date不是索引字段這兩個(gè)查詢速度也是有區(qū)別的，加函數(shù)以后要經(jīng)過幾次運(yùn)算才可以比較，不加函數(shù)，就是日期和日期的直接比較。
5、數(shù)值型的條件的常量不要加引號(hào)，這樣有可能數(shù)值型的字段會(huì)被轉(zhuǎn)成字符型，如數(shù)值型的字段c_id=123456，最好不要寫成c_id='123456'
6、全索引掃描慢于部分索引掃描，所以LIKE條件中的%_盡量放在最后面。
7、學(xué)會(huì)看查詢計(jì)劃，看下查詢的哪個(gè)部分效率低，有沒有優(yōu)化的可能。
8、采用高轉(zhuǎn)大容量大緩存的SAS盤、高緩存高速的RAID卡、多通道的高容量高速的內(nèi)存。盡量使用64位系統(tǒng)，64位系統(tǒng)字長(zhǎng)比32位大一倍，還可以使用超大內(nèi)存。32位系統(tǒng)要開啟pae啟動(dòng)參數(shù)，sql用awe分配內(nèi)存，這樣才能使用大內(nèi)存，減少磁盤的IO。
加好友 
發(fā)短信
Post By：2011/5/15 17:16:44
