英文原文：

http://www.sqlservercentral.com/articles/Execution+Plans/105810/

對于SQL Server數(shù)據(jù)庫管理員和開發(fā)來說，能夠理解和分析執(zhí)行計劃是一項非常重要且有益的技能。執(zhí)行計劃將查詢的預(yù)估花銷、索引使用和執(zhí)行的操作文檔化輸出。所有的信息對于試著加速一個慢查詢來說都是極其重要的。

這篇文章是關(guān)于圖形化執(zhí)行計劃的三部分系列文章之一。第1部分解釋了執(zhí)行計劃是什么，并討論了預(yù)估和實際執(zhí)行計劃的不同。第2部分顯示了如何創(chuàng)建預(yù)估和實際執(zhí)行計劃。最后，第3部分深入一個簡單的圖形化執(zhí)行計劃，并討論了一些最普遍的查詢中的操作。

閱讀執(zhí)行計劃

讓我們看下如何從執(zhí)行情況和執(zhí)行計劃中獲得信息。

基礎(chǔ)

圖1從[AdventureWorks2012].[Person].[Address]表上的一個簡單查詢顯示預(yù)估的執(zhí)行計劃。如你所見，它由表明操作和關(guān)聯(lián)不同操作的箭頭的圖標(biāo)組成。箭頭都指向左邊，表明執(zhí)行計劃從右邊開始并向左運行。按時間順序閱讀執(zhí)行計劃，從最右邊的操作開始并向左運行。箭頭的相對層次也表明了多少數(shù)據(jù)正被從一個操作傳遞到另一個。

圖1 一個簡單的預(yù)估執(zhí)行計劃

在圖2中，頂部操作的箭頭比它下面的兩個操作更瘦。頂部操作因此也輸出更少的行。

圖2 一個稍微復(fù)雜的執(zhí)行計劃

在創(chuàng)建了執(zhí)行計劃后，就有地方可以看到查詢的總消耗。總消耗位于最后的操作。這就是最左邊圖標(biāo)的上層，在這里，就是Select操作。將鼠標(biāo)放在Select圖標(biāo)的上面會給你一個關(guān)于操作信息的提示框（圖3）。

我們對Estimated Subtree Cost感興趣。總的消耗是一個查詢是否執(zhí)行很快的更好判斷的相對值。它由I/O消耗和CPU消耗組成。Operator Cost是I/O Cost和CPU Cost之和。在這里我們的查詢很好的低于1。它有可能執(zhí)行相對較快。另一方面，一個查詢總消耗上千可能需要相當(dāng)長時間完成。一些因素影響著預(yù)估消耗。不僅是相關(guān)表和視圖的行和索引的數(shù)量，而且環(huán)境因素例如CPU數(shù)量和磁盤都被用于計算消耗。

圖3 查看執(zhí)行計劃總消耗

在檢查了總消耗并得到一個運行時間的相對感覺后，接下來，從右到左快速查看執(zhí)行的操作。在圖1，首先，有一個聚集索引掃描。一個掃描表名查詢不是非常可選擇性（看Frequent Plan Operations下的Index/Table Scan查看更多細節(jié)）。在這個特定情況下，它是一個沒有where從句的產(chǎn)物。我們也有TOP操作，從查詢返回前1000行。最后，有一個在select語句中返回指定列的select操作。

一旦你有一個查詢正在做什么的整體感受，我們將專注在最高消耗的操作上。在每個圖標(biāo)的最下面對每個操作執(zhí)行計劃列出了總消耗的百分比。從圖1到圖2，我們看到聚集索引掃描占比總消耗的99%。我們想專注在這個操作上。

我們看下這個圖標(biāo)的提示框（看圖4），你會注意到有四個消耗列出。對于每個操作消耗分為CPU和IO消耗。Operator Cost是CPU和I/O Cost之和。Sub Tree Cost是當(dāng)前的Operator Cost加上在它之前的操作的整個操作消耗。如果你從最右邊的操作開始并跟隨箭頭向左，你會看到對每個完成的操作Sub Tree Cost累加。如我們之前查看到的，在左邊最上層的操作的Sub Tree Cost包含了整個查詢的預(yù)估的消耗。

圖4 執(zhí)行計劃消耗

常見的執(zhí)行計劃操作

下面是一些出現(xiàn)在查詢計劃里的最常用的操作。

Index/Table Seek?-- 當(dāng)執(zhí)行seek，SQL Server可以在索引里有效查找特定值或值的一個可選擇范圍。使用圖書館類比，你使用圖書館的電腦查找一本書的位置，并獲得這本書的位置。

Index/Table Scan?-- 在scan操作中，SQL Server通讀整個表或索引。再次使用圖書館類比，相當(dāng)于查找圖書館中的每一本知道找到你想要的書。試著在大型的大學(xué)圖書館這么做！Scan表明了搜索標(biāo)準(zhǔn)沒有達到足夠的使用seek操作的選擇性。如果在列上沒有索引被查找或者返回的值的數(shù)量在索引中占百分比很大（低選擇性），查看所有的值會更有效。如果你感覺有指定一個WHERE從句或JOIN足夠保證使用索引，確保列上被索引。

Seek/Scan with Bmk謂詞?-- 當(dāng)在一個索引查找或掃描的提示框的Seek Predicates部分查看，你有時會看到一個謂詞像Bmknnnn這里nnnn是數(shù)字。這表明SQL Server會創(chuàng)建一個書簽用于Index或RID Lookup。當(dāng)書簽出現(xiàn)，index seek/scan是一個兩步過程的部分，優(yōu)化器會在使用書簽創(chuàng)建了一個數(shù)據(jù)集后，執(zhí)行聚集索引查找（或表查找，如果沒有聚集索引）。查看關(guān)于Key/RID Lookup部分的更多信息。

Joins

SQL Server使用了三種join操作：

Hash Match/Join?-- Hash Match或者Join可以用于Join（Hash Join）和Group by的（Hash Match）。在這個操作中，查詢優(yōu)化器從被關(guān)聯(lián)的兩個表（如圖形化執(zhí)行計劃中所見）的上層表構(gòu)建一個哈希表。這被稱為構(gòu)造表。低層表（被稱為探測表）的每行然后搜索構(gòu)造表匹配數(shù)據(jù)。在一個Group By的情況下，之前操作的結(jié)果被用于構(gòu)造表和探測表。這類Join效率的關(guān)鍵是構(gòu)造表的大小和服務(wù)器的可用內(nèi)存數(shù)量。如果足夠小，優(yōu)化器將在內(nèi)存中創(chuàng)建構(gòu)造表。如果可能，Hash Match將會相當(dāng)快。另一方面，如果構(gòu)造表相當(dāng)大，處理過程編程一個嵌套循環(huán)并且非常慢。當(dāng)這發(fā)生的時候，Hash Match的消耗是執(zhí)行計劃的重要的百分比，你應(yīng)該使得查詢更具選擇性或者考慮增加一個索引。Hash Join和Match會在執(zhí)行前等待有足夠的內(nèi)存。

Merge Join?-- 當(dāng)上層表（如圖形化執(zhí)行計劃中所示）在Join中很大，Merge Join將會是最快的Join類型。這個Join的消耗與兩個表的行數(shù)總和相關(guān)（#上層表的行數(shù) + #下層表的行數(shù)）。Merge Join的效率的關(guān)鍵是關(guān)聯(lián)的兩個表必須在關(guān)聯(lián)列上已排序。如果表還沒有排序，優(yōu)化器將會首先排序表。在這里，你會在Merge Join操作器之前直接看到一個排序操作器。排序操作是非常消耗性能的，因此如果一個執(zhí)行計劃在Merge Join之前顯示了一個有高消耗排序操作器，你可能想在關(guān)聯(lián)列添加索引。

Nested Loop?-- 嵌套循環(huán)關(guān)聯(lián)的消耗和兩個表行數(shù)（#上層表的行數(shù) * #下層表的行數(shù)）的乘積有關(guān)。雖然這個Join沒有Merge Join有效率，當(dāng)表沒有排序時它的整體消耗比Merge Join低，當(dāng)上層表很大時它的整體消耗比比Hash Join低。再則，如果操作的消耗在執(zhí)行計劃中占很高百分比，那么讓你的查詢更具選擇性或者添加一個索引。

Key/RID Lookup?-- 當(dāng)在一個非聚集索引上執(zhí)行seek或scan時發(fā)生lookup，并且所有的數(shù)據(jù)不包含在索引中。當(dāng)這種情況發(fā)生時，如果存在聚集索引，在聚集索引上發(fā)生Key Lookup，否則如果沒有聚集索引，執(zhí)行行標(biāo)識符（RID）Lookup。Lookup是昂貴的操作，如果可能應(yīng)該避免。為了消除Lookup，將Select語句中的列添加包含在非聚集索引中的include從句中，如果可能。要是你有很多列在Select語句中，不可能將所有都包含進去，又怎樣呢？接下來最應(yīng)該做的事是使得非聚集索引比當(dāng)前正使用的索引更具選擇性。那就是說，如果你不能移除Lookup，試著減少傳遞給Lookup的行數(shù)。

Compute Scalar?-- 該操作執(zhí)行計算處理一個單一值。通常是標(biāo)量函數(shù)、算術(shù)計算或字符串聯(lián)接的結(jié)果。警告，優(yōu)化器不能預(yù)估標(biāo)量或多語句表值函數(shù)的執(zhí)行計劃。當(dāng)這些函數(shù)之一出現(xiàn)了性能低下，嘗試將它轉(zhuǎn)換為一個內(nèi)聯(lián)表值函數(shù)。

Concatenation?-- 對字符串聯(lián)接不操作；而是對于數(shù)據(jù)集合的聯(lián)接。最常用于在UNION ALL操作中國聯(lián)接數(shù)據(jù)。

Sort?-- sort操作只將非排序數(shù)據(jù)作為輸入并輸出一個排序集合。排序在大型數(shù)據(jù)集合上是非常消耗性能的。排序也需要在執(zhí)行前等待內(nèi)存足夠多。有高排序消耗的執(zhí)行計劃應(yīng)該被檢查用于優(yōu)化。

Parallelism?-- 如果SQL Server所在的機器上有不止一個處理器，可選的在多個處理器之間拆分操作。事實上，如果有多個處理器，優(yōu)化器會創(chuàng)建兩個執(zhí)行計劃，一個用于并行而一個沒有。SQL Server然后決定哪個最后可能消耗最短的時間。Parallelism致力于將數(shù)據(jù)分割在多個處理器間覆蓋操作并合并結(jié)果。如果并行操作消耗很高，你可以在查詢上使用MAXDOP查詢提示[OPTION (MAXDOP 1) ]強制使用一個處理器。

對于操作的完整列表，查看TechNet文章Showplan邏輯和物理操作參考。

總結(jié)

在查詢優(yōu)化中閱讀圖形化執(zhí)行計劃是一個非常有用的技能。該系列文章介紹了這個主題。我歡迎你對后續(xù)文章的評論。如果你也想這個主題的內(nèi)容，Grant Fritchey的書SQL Server執(zhí)行計劃提供了最好的最廣泛的涵蓋內(nèi)容。

參考

.分析查詢，TechNet Library --?http://technet.microsoft.com/en-us/library/ms191227(v=SQL.105).aspx

.分析慢查詢的清單，TechNet Library --?http://technet.microsoft.com/en-us/library/ms177500(v=sql.105).aspx

.Fritchey，Grant（2008），SQL Server執(zhí)行計劃，Simple Talk出版（本文使用2008版，2013年出版了第2版）

.Showplan邏輯和物理操作參考，TechNet Library --?http://technet.microsoft.com/en-us/library/ms191158.aspx

譯者補充：

淺談SQL Server中的三種物理連接操作

https://msdn.microsoft.com/zh-cn/library/dn144699.aspx

表值函數(shù)

表值函數(shù)提供強大的結(jié)果集生成能力。它可以在查詢內(nèi)部表或視圖允許的任何地方使用。表值函數(shù)在使用上比返回一個結(jié)果集的存儲過程更靈活，因為函數(shù)的結(jié)果集可以聯(lián)接到查詢中的其他表。

SQL Server中有兩種表值函數(shù)。內(nèi)聯(lián)表值函數(shù)在概念上與帶參數(shù)的視圖類似。多語句表值函數(shù)允許多條語句在表變量中創(chuàng)建結(jié)果集來返回。

1. 內(nèi)聯(lián)表值函數(shù)

創(chuàng)建內(nèi)聯(lián)表值函數(shù)很簡單。內(nèi)聯(lián)表值函數(shù)的內(nèi)容是一條帶參數(shù)的SELECT語句。返回數(shù)據(jù)類型永遠是表，不過返回表的結(jié)構(gòu)由SELECT語句的結(jié)構(gòu)來定義。下面是內(nèi)聯(lián)表值函數(shù)的一個例子，檢索給定CustomerID的商品銷售總量。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

USE?AdventureWorks2008; GO CREATE?FUNCTION?Sales.ufnSalesByCustomer?(@CustomerID?int) RETURNS?TABLE AS RETURN ( SELECT?P.ProductID,?P.Name,?SUM(SD.LineTotal)?AS?Total FROM?Production.Product?AS?P JOIN?Sales.SalesOrderDetail?AS?SD ON?SD.ProductID?=?P.ProductID JOIN?Sales.SalesOrderHeader?AS?SH ON?SH.SalesOrderID?=?SD.SalesOrderID WHERE?SH.CustomerID?=?@CustomerID GROUP?BY?P.ProductID,?P.Name ); GO

注意，函數(shù)體由一條RETURN語句組成。使用這個函數(shù)的一個例子如下所示：

1	SELECT?*?FROM?Sales.ufnSalesByCustomer(30052);

內(nèi)聯(lián)表值函數(shù)功能強大，在要求參數(shù)化查詢的情況下值得考慮。它們在結(jié)果集如何使用上提供更多的靈活性。

2. 多語句表值函數(shù)

多語句表值函數(shù)允許多條語句來創(chuàng)建表的內(nèi)容。多語句表值函數(shù)可以用來替換使用多個步驟來構(gòu)建結(jié)果集的存儲過程。

多語句表值函數(shù)允許開發(fā)人員使用多個步驟動態(tài)地填充表，這一點與存儲過程類似，不過它們可以在SELECT語句中像表那樣被引用。

使用多語句表值函數(shù)時，表的結(jié)構(gòu)必須在函數(shù)頭定義。要為表使用一個變量名，并且所有修改數(shù)據(jù)的操作只能引用表變量。

下面的例子是一個函數(shù)，類似上一節(jié)中創(chuàng)建的ufnSalesByCustomer。首先創(chuàng)建表變量，然后使用剛才創(chuàng)建的標(biāo)量函數(shù)來更新表變量，讓它包含總的存貨清單。創(chuàng)建函數(shù)的語句如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

USE?AdventureWorks2008; GO CREATE?FUNCTION?Sales.ufnSalesByCustomerMS?(@CustomerID?int) RETURNS?@table?TABLE (?ProductID?int?PRIMARY?KEY?NOT?NULL, ProductName?nvarchar(50)?NOT?NULL, TotalSales?numeric(38,6)?NOT?NULL, TotalInventory?int?NOT?NULL?) AS BEGIN INSERT?INTO?@table SELECT?P.ProductID,?P.Name,?SUM(SD.LineTotal)?AS?Total,?0 FROM?Production.Product?AS?P JOIN?Sales.SalesOrderDetail?SD?ON?SD.ProductID?=?P.ProductID JOIN?Sales.SalesOrderHeader?SH?ON?SH.SalesOrderID?=?SD.SalesOrderID WHERE?SH.CustomerID?=?@CustomerID GROUP?BY?P.ProductID,?P.Name; UPDATE?@table SET?TotalInventory?=?dbo.ufnGetTotalInventoryStock(ProductID); RETURN; END;

執(zhí)行這個函數(shù)與執(zhí)行前面的內(nèi)聯(lián)函數(shù)一樣：

1	SELECT?*?FROM?Sales.?ufnSalesByCustomerMS?(30052);

-------------------------------------------------------------------------------------

表值函數(shù)和標(biāo)量值函數(shù)的不同是 表值函數(shù)是返回一個Table類型 Table類型相當(dāng)與一張存儲在內(nèi)存中的一張?zhí)摂M表.

本文轉(zhuǎn)自UltraSQL51CTO博客，原文鏈接：?http://blog.51cto.com/ultrasql/1735019，如需轉(zhuǎn)載請自行聯(lián)系原作者

總結(jié)

以上是生活随笔為你收集整理的理解图形化执行计划 -- 第3部分：分析执行计划的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。