2.索引選擇 
　　對于每個可優(yōu)化的子句，優(yōu)化器都查看數(shù)據(jù)庫系統(tǒng)表，以確定是否有相關(guān)的索引能用于訪問數(shù)據(jù)。只有當(dāng)索引中的列 
的1個前綴與查詢子句中的列完全匹配時，這個索引才被認(rèn)為是有用的。因?yàn)樗饕歉鶕?jù)列的順序構(gòu)造的，所以要求匹配是 
精確的匹配。對于分簇索引，原來的數(shù)據(jù)也是根據(jù)索引列順序排序的。想用索引的次要列訪問數(shù)據(jù)，就像想在電話本中查 
找所有姓為某個姓氏的條目一樣，排序基本上沒有什么用，因?yàn)槟氵€是得查看每一行以確定它是否符合條件。如果1個子句 
有可用的索引，那么優(yōu)化器就會為它確定選擇性。 
　　所以在設(shè)計(jì)過程中，要根據(jù)查詢設(shè)計(jì)準(zhǔn)則仔細(xì)檢查所有的查詢，以查詢的優(yōu)化特點(diǎn)為基礎(chǔ)設(shè)計(jì)索引。 
　　(1)比較窄的索引具有比較高的效率。對于比較窄的索引來說，每頁上能存放較多的索引行，而且索引的級別也較少。 
所以，緩存中能放置更多的索引頁，這樣也減少了I/O操作。 
　　(2)SQL Server優(yōu)化器能分析大量的索引和合并可能性。所以與較少的寬索引相比，較多的窄索引能向優(yōu)化器提供更多 
的選擇。但是不要保留不必要的索引，因?yàn)樗鼈儗⒃黾哟鎯途S護(hù)的開支。對于復(fù)合索引、組合索引或多列索引，SQL 
Server優(yōu)化器只保留最重要的列的分布統(tǒng)計(jì)信息，這樣，索引的第1列應(yīng)該有很大的選擇性。 
　　(3)表上的索引過多會影響UPDATE、INSERT和DELETE的性能，因?yàn)樗械乃饕急仨氉鱿鄳?yīng)的調(diào)整。另外，所有的分頁 
操作都被記錄在日志中，這也會增加I/O操作?！　?nbsp;

　　(4)對1個經(jīng)常被更新的列建立索引，會嚴(yán)重影響性能。 
　　(5)由于存儲開支和I/O操作方面的原因，較小的自組索引比較大的索引性能更好一些。但它的缺點(diǎn)是要維護(hù)自組的 
列。 
　　(6)盡量分析出每一個重要查詢的使用頻度，這樣可以找出使用最多的索引，然后可以先對這些索引進(jìn)行適當(dāng)?shù)膬?yōu)化。 
　　(7)查詢中的WHERE子句中的任何列都很可能是個索引列，因?yàn)閮?yōu)化器重點(diǎn)處理這個子句。 
　　(8)對小于1個范圍的小型表進(jìn)行索引是不劃算的，因?yàn)閷τ谛”韥碚f表掃描往往更快而且費(fèi)用低。 
　　(9)與“ORDER BY”或“GROUP BY”一起使用的列一般適于做分族索引。如果“ORDER BY”命令中用到的列上有分簇索 
引，那么就不會再生成1個工作表了，因?yàn)樾幸呀?jīng)排序了?！癎ROUP BY”命令則一定產(chǎn)生1個工作表。 
　　(10)分簇索引不應(yīng)該構(gòu)造在經(jīng)常變化的列上，因?yàn)檫@會引起整行的移動。在實(shí)現(xiàn)大型交易處理系統(tǒng)時，尤其要注意這 
一點(diǎn)，因?yàn)檫@些系統(tǒng)中數(shù)據(jù)往往是頻繁變化的。 
　　3.合并選擇 
　　當(dāng)索引選擇結(jié)束，并且所有的子句都有了一個基于它們的訪問計(jì)劃的處理費(fèi)用時，優(yōu)化器開始執(zhí)行合并選擇。合并選 
擇被用來找出一個用于合并子句訪問計(jì)劃的有效順序。為了做到這一點(diǎn)，優(yōu)化器比較子句的不同排序，然后選出從物理磁 
盤I/O的角度看處理費(fèi)用最低的合并計(jì)劃。因?yàn)樽泳浣M合的數(shù)量會隨著查詢的復(fù)雜度極快地增長，SQL Server查詢優(yōu)化器使 
用樹剪枝技術(shù)來盡量減少這些比較所帶來的開支。當(dāng)這個合并選擇階段結(jié)束時，SQL Server查詢優(yōu)化器已經(jīng)生成了1個基于 
費(fèi)用的查詢執(zhí)行計(jì)劃，這個計(jì)劃充分利用了可用的索引，并以最小的系統(tǒng)開支和良好的執(zhí)行性能訪問原來的數(shù)據(jù)。 
3.2　高效的查詢選擇 
　　從以上查詢優(yōu)化的3個階段不難看出，設(shè)計(jì)出物理I/O和邏輯I/O最少的方案并掌握好處理器時間和I/O時間的平衡，是 
高效查詢設(shè)計(jì)的主要目標(biāo)。也就是說，希望設(shè)計(jì)出這樣的查詢：充分利用索引、磁盤讀寫最少、最高效地利用了內(nèi)存和CPU 
資源。 
　　以下建議是從SQL Server優(yōu)化器的優(yōu)化策略中總結(jié)出來的，對于設(shè)計(jì)高效的查詢是很有幫助的。 
　　1.如果有獨(dú)特的索引，那么帶有“＝”操作符的WHERE子句性能最好，其次是封閉的區(qū)間(范圍)，再其次是開放的區(qū) 
間。 
　　2.從數(shù)據(jù)庫訪問的角度看，含有不連續(xù)連接詞(OR和IN)的WHERE子句一般來說性能不會太好。所以，優(yōu)化器可能會采用 
R策略，這種策略會生成1個工作表，其中含有每個可能匹配的執(zhí)行的標(biāo)識符，優(yōu)化器把這些行標(biāo)志符(頁號和行號)看做是 
指向1個表中匹配的行的“動態(tài)索引”。優(yōu)化器只需掃描工作表，取出每一個行標(biāo)志符，再從數(shù)據(jù)表中取得相應(yīng)的行，所以 
R策略的代價(jià)是生成工作表。 
　　3.包含NOT、<>、或!　=的WHERE子句對于優(yōu)化器的索引選擇來說沒有什么用處。因?yàn)檫@樣的子句是排斥性的，而不是 
包括性的，所以在掃描整個原來數(shù)據(jù)表之前無法確定子句的選擇性。 
　　4.限制數(shù)據(jù)轉(zhuǎn)換和串操作，優(yōu)化器一般不會根據(jù)WHERE子句中的表達(dá)式和數(shù)據(jù)轉(zhuǎn)換式生成索引選擇。例如： 
　　paycheck * 12>36000 or substring(lastname,1,1)=“L” 
　　如果該表建立了針對paycheck和lastname的索引，就不能利用索引進(jìn)行優(yōu)化，可以改寫上面的條件表達(dá)式為： 
　　paycheck<36000/12 or lastname like “L%” 
　　5.WHERE子句中的本地變量被認(rèn)為是不被優(yōu)化器知道和考慮的，例外的情況是定義為儲備過程輸入?yún)?shù)的變量。 
　　6.如果沒有包含合并子句的索引，那么優(yōu)化器構(gòu)造1個工作表以存放合并中最小的表中的行。然后再在這個表上構(gòu)造1 
個分簇索引以完成一個高效的合并。這種作法的代價(jià)是工作表的生成和隨后的分族索引的生成，這個過程叫 
REFORMATTING?！　∷詰?yīng)該注意RAM中或磁盤上的數(shù)據(jù)庫tempdb的大小(除了SELECT INTO語句)。另外，如果這些類型的 
操作是很常見的，那么把tempdb放在RAM中對于提高性能是很有好處的。 
4　性能優(yōu)化的其他考慮 
　　上面列出了影響SQL Server的一些主要因素，實(shí)際上遠(yuǎn)不止這些。操作系統(tǒng)的影響也很大，在Windows NT下，文件系 
統(tǒng)的選擇、網(wǎng)絡(luò)協(xié)議、開啟的服務(wù)、SQL Server的優(yōu)先級等選項(xiàng)也不同程度上影響了SQL Server的性能。 
　　影響性能的因素是如此的多，而應(yīng)用又各不相同，找出1個通用的優(yōu)化方案是不現(xiàn)實(shí)的，在系統(tǒng)開發(fā)和維護(hù)的過程中必 
須針對運(yùn)行的情況，不斷加以調(diào)整。事實(shí)上，絕大部分的優(yōu)化和調(diào)整工作是在與客戶端獨(dú)立的服務(wù)器上進(jìn)行的，因此也是 
現(xiàn)實(shí)可行的。

最新評論