理解圖形化執行計劃 -- 第1部分：講解執行計劃
英文原文：
http://www.sqlservercentral.com/articles/Execution+Plan/105771/
對於SQL Server數據庫管理員和開發來說，能夠理解和分析執行計劃是一項非常重要且有益的技能。執行計劃將查詢的預估花銷、索引使用和執行的操作文檔化輸出。所有的信息對於試着加速一個慢查詢來說都是極其重要的。
這篇文章是關於圖形化執行計劃的三部分系列文章之一。第1部分解釋了執行計劃是什麼，並討論了預估和實際執行計劃的不同。第2部分顯示瞭如何創建預估和實際執行計劃。最後，第3部分深入一個簡單的圖形化執行計劃，並討論了一些最普遍的查詢中的操作。
什麼是執行計劃？
查詢優化器是SQL Server的一個組件，用於分析查詢的信息和相關表、索引和索引視圖的可用統計信息。統計信息允許查詢比較表中大量的行與索引中的唯一值，來決定哪個索引會降低查詢的消耗。
查詢優化器使用統計信息來創建一些不同的執行計劃。每個執行計劃是一步步的操作文檔和這些操作的順序，可用於返回查詢結果的一種方式被執行。不同的執行計劃會嘗試使用不同的索引，查找或掃描（更多關於查找和掃描的在第3部分），不同類型的連接（查看第3部分更多關於連接），和以不同順序的操作找到最佳執行計劃。
接下來，優化器針對每個操作分配相對消耗的I/O和處理器。然後對於每個執行計劃的每個操作的消耗求和來生成總的消耗。在完成一些不同的執行計劃後，它然後選擇最低消耗的執行計劃，並且使用該計劃執行查詢。重要的是記住這些消耗是優化器計算的相對值，並且不能與任何完成執行的真實值比較（例如CPU和I/O時間）。
一旦執行計劃被優化器選擇，它會被存儲在緩存中。下一次查詢被執行，優化器會查找緩存看是否對這個查詢包含有執行計劃。如果執行計劃被找到，它將被用於執行這個查詢，節省了創建新的預估執行計劃的時間。
非圖形化執行計劃
除了圖形化執行計劃，也有純文本和XML格式執行計劃。純文本執行計劃是微軟可用的第一種執行計劃，並且難以閱讀。伴隨着XML格式執行計劃的出現，微軟將會在將來版本的SQL Server中廢棄純文本執行計劃。XML執行計劃的關鍵價值是它們可以被保存並之後以圖形化執行計劃打開。以XML格式保存執行計劃，查看導出執行計劃或者TechNet文章“以XML格式保存執行計劃”。關於純文本和XML執行計劃的更多信息，查看Grant Fritchey的書SQL Server執行計劃。
預估執行計劃 VS 實際執行計劃
有兩種類型的執行計劃：預估和實際。預估的執行計劃是在執行之前由查詢優化器計算；它表明優化器信任爲最低消耗的執行計劃。通常大約在幾秒之內返回給用戶。實際執行計劃，另一方面，處理查詢過程中實際執行的步驟。在查詢完成後實際的計劃被返回。有時，預估和實際的值會不同。在執行計劃中值爲定量數據。查看圖1對於一些執行計劃值的一個示例。
爲什麼預估和實際執行計劃值不同？
有三個原因來解釋爲什麼執行計劃值不同。
1.預估執行計劃不能被創建
在查詢優化器對查詢創建預估的執行計劃之前，Algebrizer組件會驗證查詢。如果一個對象在查詢中不存在，驗證失敗並且沒有創建預估的執行計劃。這種情況，當一個創建語句位於使用這個創建對象的相同批中。
2.陳舊的統計信息
SQL Server對每個索引創建關於每個列值的分佈的統計信息。當查詢優化器預估從一個操作返回的行數的時候，使用該信息，並且完全使用一個特定索引的消耗來預估。當在表中數據改變時，這些統計信息過期。如果查詢優化器使用壞的統計信息，它會錯誤的計算執行計劃的消耗。通過比較預估行數和實際行數，你可以看到在實際執行計劃中一個操作的差異（見圖1）。圖1中高亮顯示的差異是對錶執行一個刪除操作產生的。
3.並行性
如果安裝SQL Server的機器有多個CPU，查詢優化器會完成兩次尋找最低消耗執行計劃的過程；創建一個執行計劃使用一個處理器，第二個執行計劃利用多個處理器（並行性）。直到執行時纔會決定運行這兩個執行計劃中的哪個。當用戶請求查看預估執行計劃，只有一個執行計劃被顯示。這個執行計劃可能是、也可能不是當執行查詢時查詢引擎所選擇的那個。
圖1 比較EstimatedNumber of Rows和Actual Number of Rows
哪個執行計劃更好？
一個預估執行計劃幾乎立即被返回，而實際執行計劃不能。實際的執行計劃給出了一個更加完整的圖片，但是在生產環境中，爲了獲得實際執行計劃而等待一個長時間運行的語句執行完成是不切實際的。
只有在實際執行計劃中找到的最頻繁使用信息，是從每個操作返回的實際行數。實際行數可以與預估行數比較。如果差異巨大，那麼統計信息很可能過時了。在這種情況下更新統計信息可能會提高查詢性能（查看TechNet文章“統計信息”獲得更多關於這個話題的信息）。
另一種獲得實際行數的方式是，檢查表的索引統計信息的最後時間已更新。將該信息與數據庫的活動聯繫起來，將會表名統計信息的陳舊情況。以下查詢運行在sys.indexes表返回已更新的統計信息的最後日期：
USE YourDatabase
GO
SELECT name AS index_name
, STATS_DATE(OBJECT_ID, index_id) AS StatsUpdated
FROM sys.indexes
WHERE OBJECT_ID = OBJECT_ID('YourSchema.YourTable')只在實際執行計劃中找到的其他信息
Actual Rewinds和Rebinds的值只會應用到少數幾個操作。這些值計數特定操作初始化的次數。大量的初始化可能導致高I/O使用。對於該話題更完整的涵蓋，看看Grant Fritchey的書SQL Server執行計劃。
除了Actual Rewinds和Rebinds，Number of Executions在SQL Server 2008中引入。該值是一個操作被執行次數的計數。對一些操作，執行次數和返回行數相關，預估和實際的執行次數會根據預估和實際行數的不同而不同。在某些情況下，SQL Server不能預估執行計數，將會在Estimated Number of Executions顯示值爲1。
預估的執行計劃包含預估的消耗，邏輯上導致實際執行計劃包含實際消耗。然而，情況並非如此。正如之前提到的，計數值只是表明一個操作時間消耗上的相對昂貴程度。它不與任何實際值如CPU和I/O時間相關。
總結
圖形化執行計劃顯示了所有操作的細節和它們將用於執行查詢的順序（或許是實際執行計劃）。這使得它們對分析和優化慢查詢是一個出色的工具。預估和實際的執行計劃都有它們的優勢和缺點。每個適合在特定的環境下。閱讀該系列的第2部分和第3部分獲得更多關於圖形化執行計劃的信息。
參考
.顯示圖形化執行計劃（SQL Server Management Studio），TechNet Library -- http://technet.microsoft.com/en-us/library/ms178071(v=sql.105).aspx
.執行計劃緩存和重用，TechNet Library -- http://technet.microsoft.com/en-us/library/ms181055(v=SQL.105).aspx
.Fritchey，Grant（2008），SQL Server執行計劃，Simple Talk出版（本文使用2008版，在2013年第2版發行） -- http://technet.microsoft.com/en-us/library/ms191158.aspx
譯者補充：
分析——》綁定——》優化
分析：檢查，例如檢查使用分隔標識符的表或列名稱是否以數字開頭，分析幾乎是所有編程語言編譯器的一項常規操作。
綁定：確定SQL語句所引用對象的特徵檢查請求語義是否有意義，例如檢查From A join B的查詢時，如果A是一個表B是一個存儲過程，則綁定失敗。
優化：類似於綁定，優化器一次只優化批處理中的一條語句，在編譯器爲該批處理生成執行計劃並存儲到plan cache之後將執行該計劃的執行上下文（execute context）的特殊副本。sqlserver像緩存執行計劃一樣緩存執行上下文。sqlserver並不優化batch中的每條sql語句，他只優化那些訪問表而且可能生成多個執行計劃的語句，sqlserver優化所有的DML。只有被優化過的語句纔會生成執行計劃。
執行計劃指標值
logical operation：基於微軟查詢處理概念模型的邏輯操作。例如，聯接運算符的physical operation屬性表示聯接算法（nested loops，merge ，hash）物理運算符
logical operation屬性表示邏輯聯接類型（Inner join，outer join，semi join 等等）邏輯運算符
如果沒有與該運算符關聯的邏輯操作，則這項度量的值與physical operation相同
actual number of rows：從該運算符實際返回的行數（只顯示在實際的計劃中）
estimated I/O cost和estimated cpu cost：運算符在特定資源上的估計成本（I/O或CPU）這兩個度量將幫助你確定運算符是否是I/O密集或CPU密集的
例如，你可以看到clustered index seek運算符主要與I/O有關，而hash match運算符主要與cpu有關
estimated operator cost：執行該操作的成本
estimated subtree cost：如前所述，他表示到當前節點爲止整個子樹的累積成本
estimated number of rows：該運算符預計的返回行數。在有些情況下，通過觀察實際行數和估計行數之間的差異，你可以找出因統計信息不足或其他原因而導致的成本問題
estimated row size：你可能會奇怪爲什麼在實際的查詢計劃中沒有顯示該屬性的實際值。因爲你的表可能包含可變長度類型，表中行的大小各異
actual rebinds和actual rewinds：這兩個度量僅與作爲nested loops聯接內側的運算符有關，在其他運算符中，rebinds將顯示爲1，rewinds將顯示爲0
他們表示內部init方法被調用的次數。重新綁定次數和重繞次數之和等於聯接外側所處理的行數。重新綁定意味着聯接的一個或多個參數發生更改後，必須重新計劃
聯接的內側。重繞意味着任何相關參數都沒有發生更改，可以重用之前的內側結果集