以下的文章主要是介紹SQL Server優化如何通過3個階段來完成，查詢分析、索引選擇以及合并選擇。以下就是正文的主要內容的詳細內容的介紹，望會大家以后的學習或是工作中帶來很大的幫助。

1.查詢分析

在查詢分析階段，SQL Server優化器查看每一個由正規查詢樹代表的子句，并判斷它是否能被優化。SQL Server優化一般會盡量優化那些限制掃描的子句。例如，搜索和/或合并子句。但是不是所有合法的SQL語法都可以分成可優化的子句，如含有SQL不等關系符“<>”的子句。

因為“<>”是1個排斥性的操作符，而不是1個包括性的操作符，所在掃描整個表之前無法確定子句的選擇范圍會有多大。當1個關系型查詢中含有不可SQL Server優化的子句時，執行計劃用表掃描來訪問查詢的這個部分，對于查詢樹中可優化的SQL Server子句，則由優化器執行索引選擇。

2.索引選擇

對于每個可優化的子句，優化器都查看數據庫系統表，以確定是否有相關的索引能用于訪問數據。只有當索引中的列的1個前綴與查詢子句中的列完全匹配時，這個索引才被認為是有用的。因為索引是根據列的順序構造的，所以要求匹配是精確的匹配。

對于分簇索引，原來的數據也是根據索引列順序排序的。想用索引的次要列訪問數據，就像想在電話本中查找所有姓為某個姓氏的條目一樣，排序基本上沒有什么用，因為你還是得查看每一行以確定它是否符合條件。如果1個子句有可用的索引，那么優化器就會為它確定選擇性。

所以在設計過程中，要根據查詢設計準則仔細檢查所有的查詢，以查詢的優化特點為基礎設計索引。

(1)比較窄的索引具有比較高的效率。對于比較窄的索引來說，每頁上能存放較多的索引行，而且索引的級別也較少。所以，緩存中能放置更多的索引頁，這樣也減少了I/O操作。

(2)SQL Server優化器能分析大量的索引和合并可能性。所以與較少的寬索引相比，較多的窄索引能向優化器提供更多的選擇。但是不要保留不必要的索引，因為它們將增加存儲和維護的開支。對于復合索引、組合索引或多列索引，SQL Server優化器只保留最重要的列的分布統計信息，這樣，索引的第1列應該有很大的選擇性。

(3)表上的索引過多會影響UPDATE、INSERT和DELETE的性能，因為所有的索引都必須做相應的調整。另外，所有的分頁操作都被記錄在日志中，這也會增加I/O操作。

(4)對1個經常被更新的列建立索引，會嚴重影響性能。

(5)由于存儲開支和I/O操作方面的原因，較小的自組索引比較大的索引性能更好一些。但它的缺點是要維護自組的列。

(6)盡量分析出每一個重要查詢的使用頻度，這樣可以找出使用最多的索引，然后可以先對這些索引進行適當的優化。

(7)查詢中的WHERE子句中的任何列都很可能是個索引列，因為優化器重點處理這個子句。

(8)對小于1個范圍的小型表進行索引是不劃算的，因為對于小表來說表掃描往往更快而且費用低。

(9)與“ORDER BY”或“GROUP BY”一起使用的列一般適于做分族索引。如果“ORDER BY”命令中用到的列上有分簇索引，那么就不會再生成1個工作表了，因為行已經排序了。“GROUP BY”命令則一定產生1個工作表。

(10)分簇索引不應該構造在經常變化的列上，因為這會引起整行的移動。在實現大型交易處理系統時，尤其要注意這一點，因為這些系統中數據往往是頻繁變化的。

3.合并選擇

當索引選擇結束，并且所有的子句都有了一個基于它們的訪問計劃的處理費用時，優化器開始執行合并選擇。合并選擇被用來找出一個用于合并子句訪問計劃的有效順序。為了做到這一點，優化器比較子句的不同排序，然后選出從物理磁盤I/O的角度看處理費用***的合并計劃。

因為子句組合的數量會隨著查詢的復雜度極快地增長，SQL Server查詢優化器使用樹剪枝技術來盡量減少這些比較所帶來的開支。當這個合并選擇階段結束時，SQL Server優化查詢優化器已經生成了1個基于費用的查詢執行計劃，這個計劃充分利用了可用的索引，并以最小的系統開支和良好的執行性能訪問原來的數據。

3.2　高效的查詢選擇

從以上查詢優化的3個階段不難看出，設計出物理I/O和邏輯I/O最少的方案并掌握好處理器時間和I/O時間的平衡，是高效查詢設計的主要目標。也就是說，希望設計出這樣的查詢:充分利用索引、磁盤讀寫最少、***效地利用了內存和CPU資源。

以下建議是從SQL Server優化器的優化策略中總結出來的，對于設計高效的查詢是很有幫助的。

1.如果有獨特的索引，那么帶有“=”操作符的WHERE子句性能***，其次是封閉的區間(范圍)，再其次是開放的區間。

2.從數據庫訪問的角度看，含有不連續連接詞(OR和IN)的WHERE子句一般來說性能不會太好。所以，優化器可能會采用R策略，這種策略會生成1個工作表，其中含有每個可能匹配的執行的標識符，優化器把這些行標志符(頁號和行號)看做是指向1個表中匹配的行的“動態索引”。優化器只需掃描工作表，取出每一個行標志符，再從數據表中取得相應的行，所以R策略的代價是生成工作表。

3.包含NOT、<>、或!　=的WHERE子句對于SQL Server優化器的索引選擇來說沒有什么用處。因為這樣的子句是排斥性的，而不是包括性的，所以在掃描整個原來數據表之前無法確定子句的選擇性。

4.限制數據轉換和串操作，優化器一般不會根據WHERE子句中的表達式和數據轉換式生成索引選擇。例如:

paycheck * 12>36000 or substring(lastname,1,1)=“L” 

如果該表建立了針對paycheck和lastname的索引，就不能利用索引進行優化，可以改寫上面的條件表達式為:

paycheck<36000/12 or lastname like “L%” 

5.WHERE子句中的本地變量被認為是不被優化器知道和考慮的，例外的情況是定義為儲備過程輸入參數的變量。

6.如果沒有包含合并子句的索引，那么優化器構造1個工作表以存放合并中最小的表中的行。然后再在這個表上構造1個分簇索引以完成一個高效的合并。這種作法的代價是工作表的生成和隨后的分族索引的生成，這個過程叫REFORMATTING。

所以應該注意RAM中或磁盤上的數據庫tempdb的大小(除了SELECT INTO語句)。另外，如果這些類型的操作是很常見的，那么把tempdb放在RAM中對于提高性能是很有好處的。

4　性能優化的其他考慮

上面列出了影響SQL Server優化的一些主要因素，實際上遠不止這些。操作系統的影響也很大，在Windows NT下，文件系統的選擇、網絡協議、開啟的服務、SQL Server的優先級等選項也不同程度上影響了SQL Server的性能。

影響性能的因素是如此的多，而應用又各不相同，找出1個通用的SQL Server優化方案是不現實的，在系統開發和維護的過程中必須針對運行的情況，不斷加以調整。事實上，絕大部分的優化和調整工作是在與客戶端獨立的服務器上進行的，因此也是現實可行的。

【編輯推薦】

1. SQL Server合并復制性能的提高有哪些方案？
2. SQL Server Compact中的DLL文件與工具
3. SQL Server數據庫在安裝時的注意事項
4. SQL Server 2005數據庫安裝實例演示
5. SQL Server 2000全文檢索的使用方案描述