對于SQL Server的優化來說，優化查詢可能是很常見的事情。由于數據庫的優化，本身也是一個涉及面比較的廣的話題， 因此本文只談優化查詢時如何看懂SQL Server查詢計劃。畢竟我對SQL Server的認識有限，如有錯誤，也懇請您在發現后及時批評指正。

首先，打開【SQL Server Management Studio】，輸入一個查詢語句看看SQL Server是如何顯示查詢計劃的吧。
說明：本文所演示的數據庫，是我為一個演示程序專用準備的數據庫，可以在此網頁中下載。

select v.OrderID, v.CustomerID, v.CustomerName, v.OrderDate, v.SumMoney, v.Finished
from  OrdersView as v
where v.OrderDate >= '2010-12-1' and v.OrderDate  '2011-12-1';

其中，OrdersView是一個視圖，其定義如下：

SELECT   dbo.Orders.OrderID, dbo.Orders.CustomerID, dbo.Orders.OrderDate, 
      dbo.Orders.SumMoney, dbo.Orders.Finished, 
      ISNULL(dbo.Customers.CustomerName, N'') AS CustomerName
FROM     dbo.Orders LEFT OUTER JOIN
        dbo.Customers ON dbo.Orders.CustomerID = dbo.Customers.CustomerID

對于前一句查詢，SQL Server給出的查詢計劃如下（點擊工具欄上的【顯示估計的執行計劃】按鈕）：

從這個圖中，我們至少可以得到3個有用的信息：

1. 哪些執行步驟花費的成本比較高。顯然，最右邊的二個步驟的成本是比較高的。
2. 哪些執行步驟產生的數據量比較多。對于每個步驟所產生的數據量， SQL Server的執行計劃是用【線條粗細】來表示的，因此也很容易地從分辨出來。
3. 每一步執行了什么樣的動作。

對于一個比較慢的查詢來說，我們通常要知道哪些步驟的成本比較高，進而，可以嘗試一些改進的方法。 一般來說，如果您不能通過：提高硬件性能或者調整OS,SQL Server的設置之類的方式來解決問題，那么剩下的可選方法通常也只有以下這些了：

1. 為【scan】這類操作增加相應字段的索引。
2. 有時重建索引或許也是有效的，具體情形請參考后文。
3. 調整語句結構，引導SQL Server采用其它的查詢方案去執行。
4. 調整表結構（分表或者分區）。

下面再來說說一些很重要的理論知識，這些內容對于執行計劃的理解是很有幫助的。

回到頂部SQL Server 查找記錄的方法

說到這里，不得不說SQL Server的索引了。SQL Server有二種索引：聚集索引和非聚集索引。二者的差別在于：【聚集索引】直接決定了記錄的存放位置， 或者說：根據聚集索引可以直接獲取到記錄。【非聚集索引】保存了二個信息：1.相應索引字段的值，2.記錄對應聚集索引的位置（如果表沒有聚集索引則保存記錄指針）。 因此，如果能通過【聚集索引】來查找記錄，顯然也是最快的。

SQL Server 會有以下方法來查找您需要的數據記錄：

1. 【Table Scan】：遍歷整個表，查找所有匹配的記錄行。這個操作將會一行一行的檢查，當然，效率也是最差的。
2. 【Index Scan】：根據索引，從表中過濾出來一部分記錄，再查找所有匹配的記錄行，顯然比第一種方式的查找范圍要小，因此比【Table Scan】要快。
3. 【Index Seek】：根據索引，定位（獲取）記錄的存放位置，然后取得記錄，因此，比起前二種方式會更快。
4. 【Clustered Index Scan】：和【Table Scan】一樣。注意：不要以為這里有個Index，就認為不一樣了。 其實它的意思是說：按聚集索引來逐行掃描每一行記錄，因為記錄就是按聚集索引來順序存放的。 而【Table Scan】只是說：要掃描的表沒有聚集索引而已，因此這二個操作本質上也是一樣的。
5. 【Clustered Index Seek】：直接根據聚集索引獲取記錄，最快！

所以，當發現某個查詢比較慢時，可以首先檢查哪些操作的成本比較高，再看看那些操作在查找記錄時， 是不是【Table Scan】或者【Clustered Index Scan】，如果確實和這二種操作類型有關，則要考慮增加索引來解決了。 不過，增加索引后，也會影響數據表的修改動作，因為修改數據表時，要更新相應字段的索引。所以索引過多，也會影響性能。 還有一種情況是不適合增加索引的：某個字段用0或1表示的狀態。例如可能有絕大多數是1，那么此時加索引根本就沒有意義。 這時只能考慮為0或者1這二種情況分開來保存了，分表或者分區都是不錯的選擇。

如果不能通過增加索引和調整表來解決，那么可以試試調整語句結構，引導SQL Server采用其它的查詢方案去執行。 這種方法要求： 1.對語句所要完成的功能很清楚， 2.對要查詢的數據表結構很清楚， 3.對相關的業務背景知識很清楚。 如果能通過這種方法去解決，當然也是很好的解決方法了。不過，有時SQL Server比較智能，即使你調整語句結構，也不會影響它的執行計劃。

如何比較二個相同功能的SQL語句的性能好壞呢，我建議采用二種方法： 1. 直接把二個查詢語句放在【SQL Server Management Studio】，然后去看它們的【執行計劃】，SQL Server會以百分比的方式告訴你二個查詢的【查詢開銷】。 這種方法簡單，通常也是可以參考的，不過，有時也會不準，具體原因請接著往下看(可能索引統計信息過舊)。
2. 根據真實的程序調用，寫相應的測試代碼去調用：這種方法就麻煩一些，但是它更能代表現實調用情況， 得到的結果也是更具有參考價值的，因此也是值得的。

回到頂部SQL Server Join 方式

在SQL Server中，每個join命令，都會在內部執行時采用三種更具體的方式來運行：

1. 【Nested Loops join】，如果一個聯接輸入很小，而另一個聯接輸入很大而且已在其聯接列上創建了索引， 則索引 Nested Loops 連接是最快的聯接操作，因為它們需要的 I/O 和比較都最少。

嵌套循環聯接也稱為“嵌套迭代”，它將一個聯接輸入用作外部輸入表（顯示為圖形執行計劃中的頂端輸入），將另一個聯接輸入用作內部（底端）輸入表。外部循環逐行處理外部輸入表。內部循環會針對每個外部行執行，在內部輸入表中搜索匹配行。可以用下面的偽碼來理解：

foreach(row r1 in outer table)
  foreach(row r2 in inner table)
    if( r1, r2 符合匹配條件 )
      output(r1, r2);

最簡單的情況是，搜索時掃描整個表或索引；這稱為“單純嵌套循環聯接”。如果搜索時使用索引，則稱為“索引嵌套循環聯接”。如果將索引生成為查詢計劃的一部分（并在查詢完成后立即將索引破壞），則稱為“臨時索引嵌套循環聯接”。查詢優化器考慮了所有這些不同情況。

如果外部輸入較小而內部輸入較大且預先創建了索引，則嵌套循環聯接尤其有效。在許多小事務中（如那些只影響較小的一組行的事務），索引嵌套循環聯接優于合并聯接和哈希聯接。但在大型查詢中，嵌套循環聯接通常不是最佳選擇。

2. 【Merge Join】，如果兩個聯接輸入并不小但已在二者聯接列上排序（例如，如果它們是通過掃描已排序的索引獲得的），則合并聯接是最快的聯接操作。如果兩個聯接輸入都很大，而且這兩個輸入的大小差不多，則預先排序的合并聯接提供的性能與哈希聯接相近。但是，如果這兩個輸入的大小相差很大，則哈希聯接操作通常快得多。

合并聯接要求兩個輸入都在合并列上排序，而合并列由聯接謂詞的等效 (ON) 子句定義。通常，查詢優化器掃描索引（如果在適當的一組列上存在索引），或在合并聯接的下面放一個排序運算符。在極少數情況下，雖然可能有多個等效子句，但只用其中一些可用的等效子句獲得合并列。

由于每個輸入都已排序，因此 Merge Join 運算符將從每個輸入獲取一行并將其進行比較。例如，對于內聯接操作，如果行相等則返回。如果行不相等，則廢棄值較小的行并從該輸入獲得另一行。這一過程將重復進行，直到處理完所有的行為止。

合并聯接操作可以是常規操作，也可以是多對多操作。多對多合并聯接使用臨時表存儲行（會影響效率）。如果每個輸入中有重復值，則在處理其中一個輸入中的每個重復項時，另一個輸入必須重繞到重復項的開始位置。 可以創建唯一索引告訴SQL Server不會有重復值。

如果存在駐留謂詞，則所有滿足合并謂詞的行都將對該駐留謂詞取值，而只返回那些滿足該駐留謂詞的行。

合并聯接本身的速度很快，但如果需要排序操作，選擇合并聯接就會非常費時。然而，如果數據量很大且能夠從現有 B 樹索引中獲得預排序的所需數據，則合并聯接通常是最快的可用聯接算法。

3. 【Hash Join】，哈希聯接可以有效處理未排序的大型非索引輸入。它們對復雜查詢的中間結果很有用，因為： 1. 中間結果未經索引（除非已經顯式保存到磁盤上然后創建索引），而且通常不為查詢計劃中的下一個操作進行適當的排序。 2. 查詢優化器只估計中間結果的大小。由于對于復雜查詢，估計可能有很大的誤差，因此如果中間結果比預期的大得多，則處理中間結果的算法不僅必須有效而且必須適度弱化。

哈希聯接可以減少使用非規范化。非規范化一般通過減少聯接操作獲得更好的性能，盡管這樣做有冗余之險（如不一致的更新）。哈希聯接則減少使用非規范化的需要。哈希聯接使垂直分區（用單獨的文件或索引代表單個表中的幾組列）得以成為物理數據庫設計的可行選項。

哈希聯接有兩種輸入：生成輸入和探測輸入。查詢優化器指派這些角色，使兩個輸入中較小的那個作為生成輸入。

哈希聯接用于多種設置匹配操作：內部聯接；左外部聯接、右外部聯接和完全外部聯接；左半聯接和右半聯接；交集；聯合和差異。此外，哈希聯接的某種變形可以進行重復刪除和分組，例如 SUM(salary) GROUP BY department。這些修改對生成和探測角色只使用一個輸入。

哈希聯接又分為3個類型：內存中的哈希聯接、Grace 哈希聯接和遞歸哈希聯接。

內存中的哈希聯接：哈希聯接先掃描或計算整個生成輸入，然后在內存中生成哈希表。根據計算得出的哈希鍵的哈希值，將每行插入哈希存儲桶。如果整個生成輸入小于可用內存，則可以將所有行都插入哈希表中。生成階段之后是探測階段。一次一行地對整個探測輸入進行掃描或計算，并為每個探測行計算哈希鍵的值，掃描相應的哈希存儲桶并生成匹配項。

Grace 哈希聯接：如果生成輸入大于內存，哈希聯接將分為幾步進行。這稱為“Grace 哈希聯接”。每一步都分為生成階段和探測階段。首先，消耗整個生成和探測輸入并將其分區（使用哈希鍵上的哈希函數）為多個文件。對哈希鍵使用哈希函數可以保證任意兩個聯接記錄一定位于相同的文件對中。因此，聯接兩個大輸入的任務簡化為相同任務的多個較小的實例。然后將哈希聯接應用于每對分區文件。

遞歸哈希聯接：如果生成輸入非常大，以至于標準外部合并的輸入需要多個合并級別，則需要多個分區步驟和多個分區級別。如果只有某些分區較大，則只需對那些分區使用附加的分區步驟。為了使所有分區步驟盡可能快，將使用大的異步 I/O 操作以便單個線程就能使多個磁盤驅動器繁忙工作。

在優化過程中不能始終確定使用哪種哈希聯接。因此，SQL Server 開始時使用內存中的哈希聯接，然后根據生成輸入的大小逐漸轉換到 Grace 哈希聯接和遞歸哈希聯接。
如果優化器錯誤地預計兩個輸入中哪個較小并由此確定哪個作為生成輸入，生成角色和探測角色將動態反轉。哈希聯接確保使用較小的溢出文件作為生成輸入。這一技術稱為“角色反轉”。至少一個文件溢出到磁盤后，哈希聯接中才會發生角色反轉。

說明：您也可以顯式的指定聯接方式，SQL Server會盡量尊重您的選擇。比如你可以這樣寫：inner loop join, left outer merge join, inner hash join
但是，我還是建議您不要這樣做，因為SQL Server的選擇基本上都是正確的，不信您可以試一下。

好了，說了一大堆理論東西，再來個實際的例子解釋一下吧。

回到頂部更具體執行過程

前面，我給出一張圖片，它反映了SQL Server在執行某個查詢的執行計劃，但它反映的信息可能不太細致，當然，您可以把鼠標指標移動某個節點上，會有以下信息出現：

剛好，我裝的是中文版的，上面都是漢字，我也不多說了。我要說的是另一種方式的執行過程，比這個包含更多的執行信息， 而且是實際的執行情況。（當然，您也可以繼續使用圖形方式，在運行查詢前點擊工具欄上的【包括實際的執行計劃】按鈕）

讓我們再次回到【SQL Server Management Studio】，輸入以下語句，然后執行。

set statistics profile on 

select v.OrderID, v.CustomerID, v.CustomerName, v.OrderDate, v.SumMoney, v.Finished
from  OrdersView as v
where v.OrderDate >= '2010-12-1' and v.OrderDate  '2011-12-1';

注意：現在加了一句，【set statistics profile on 】，得到的結果如下：

可以從圖片上看到，執行查詢后，得到二個表格，上面的表格顯示了查詢的結果，下面的表格顯示了查詢的執行過程。相比本文的第一張圖片， 這張圖片可能在直觀上不太友好，但是，它能反映更多的信息，而且尤其在比較復雜的查詢時，可能看起來更容易，因為對于復雜的查詢，【執行計劃】的步驟太多，圖形方式會造成圖形過大，不容易觀察。 而且這張執行過程表格能反映2個很有價值的數據（前二列）。

還是來看看這個【執行過程表格】吧。我來挑幾個重要的說一下。
【Rows】：表示在一個執行步驟中，所產生的記錄條數。（真實數據，非預期）
【Executes】：表示某個執行步驟被執行的次數。（真實數據，非預期）
【Stmt Text】：表示要執行的步驟的描述。
【EstimateRows】：表示要預期返回多少行數據。

在這個【執行過程表格】中，對于優化查詢來說，我認為前三列是比較重要的。對于前二列，我上面也解釋了，意思也很清楚。 前二列的數字也大致反映了那些步驟所花的成本，對于比較慢的查詢中，應該留意它們。 【Stmt Text】會告訴你每個步驟做了什么事情。對于這種表格，它所要表達的其實是一種樹型信息（一行就表示在圖形方式下的一個節點）， 所以，我建議從最內層開始去讀它們。做為示例，我來解釋一下這張表格它所表達的執行過程。

第5行：【Clustered Index Seek(OBJECT:([MyNorthwind].[dbo].[Customers].[PK_Customers]), SEEK:([MyNorthwind].[dbo].[Customers].[CustomerID]=[MyNorthwind].[dbo].[Orders].[CustomerID]) ORDERED FORWARD)】， 意思是說，SQL Server在對表Customers做Seek操作，而且是按照【Clustered Index Seek】的方式，對應的索引是【PK_Customers】，seek的值來源于[Orders].[CustomerID]

第4行：【Clustered Index Scan(OBJECT:([MyNorthwind].[dbo].[Orders].[PK_Orders]), WHERE:([MyNorthwind].[dbo].[Orders].[OrderDate]>='2010-12-01 00:00:00.000' AND [MyNorthwind].[dbo].[Orders].[OrderDate]'2011-12-01 00:00:00.000'))】， 意思是說，SQL Server在對表Customers做Scan操作，即：最差的【表掃描】的方式，原因是，OrderDate列上沒有索引，所以只能這樣了。

第3行：【Nested Loops(Left Outer Join, OUTER REFERENCES:([MyNorthwind].[dbo].[Orders].[CustomerID]))】， 意思是說，SQL Server把第5行和第4行產生的數據用【Nested Loops】的方式聯接起來，其中Outer表是Orders，要聯接的匹配操作也在第5行中指出了。

第2行：【Compute Scalar(DEFINE:([Expr1006]=isnull([MyNorthwind].[dbo].[Customers].[CustomerName],N'')))】， 意思是說，要執行一個isnull()函數的調用。具體原因請參考本文前部分中給出視圖定義代碼。

第1行：【SELECT [v].[OrderID],[v].[CustomerID],[v].[CustomerName],[v].[OrderDate],[v].[SumMoney],[v].[Finished] FROM [OrdersView] [v] WHERE [v].[OrderDate]>=@1 AND [v].[OrderDate]@2】， 通常第1行就是整個查詢，表示它的返回值。

回到頂部索引統計信息：查詢計劃的選擇依據

前面一直說到【執行計劃】，既然是計劃，就表示要在具體執行前就能確定下來的操作方案。那么SQL Server是如何選擇一個執行計劃的呢？ SQL Server怎么知道什么時候該用索引或者用哪個索引呢？ 對于SQL Server來說，每當要執行一個查詢時，都要首先檢查這個查詢的執行計劃是否存在緩存中，如果沒有，就要生成一個執行計劃， 具體在產生執行計劃時，并不是看有哪些索引可用（隨機選擇），而是會參考一種被稱為【索引統計信息】的數據。 如果您仔細地看一下前面的執行計劃或者執行過程表格，會發現SQL Server能預估每個步驟所產生的數據量， 正是因為SQL Server能預估這些數據量，SQL Server才能選擇一個它認為最合適的方法去執行查詢過程， 此時【索引統計信息】就能告訴SQL Server這些信息。 說到這里，您是不是有點好奇呢，為了讓您對【索引統計信息】有個感性的認識，我們來看看【索引統計信息】是個什么樣子的。 請在【SQL Server Management Studio】，輸入以下語句，然后執行。

dbcc show_statistics (Products, IX_CategoryID)

得到的結果如下圖：

首先，還是解釋一下命令：【dbcc show_statistics】這個命令可以顯示我們想知道的【索引統計信息】，它需要二個參數，1. 表名，2. 索引名

再來看看命令的結果，它有三個表格組成：
1. 第一個表格，它列出了這個索引統計信息的主要信息。