SQL執(zhí)行計劃中會有許多跡象表明查詢中可能存在不良性能點。例如，與整體查詢成本相關(guān)的成本最高的最昂貴運算符是查詢性能故障排除的良好起點。此外，后面跟著細(xì)箭頭的粗箭頭表示正在處理大量記錄并從一個運算符流向另一個運算符以檢索少量記錄，這也可能是缺少索引或性能問題的標(biāo)志。

在了解了本系列中討論的每個計劃運算符的作用之后，你可以識別出由于額外開銷而降低查詢性能的額外運算符。此外，用于掃描整個表或索引的Scan運算符表明大多數(shù)情況下存在缺少索引、索引使用不當(dāng)或查詢不包含過濾條件。執(zhí)行計劃中查詢中性能問題的另一個標(biāo)志是執(zhí)行計劃警告。這些消息用于警告查詢的不同問題以進(jìn)行故障排除，例如tempdb溢出問題、缺少索引或錯誤的基數(shù)估計。

要了解如何使用SQL執(zhí)行計劃來調(diào)整性能，讓我們通過我們的實例演示。在開始第一個示例之前，我們將使用以下create TABLE語句創(chuàng)建兩個新表：

然后使用ApexSQL Generate向每個表中插入100k條記錄

調(diào)優(yōu)簡單的查詢
假設(shè)我們需要調(diào)優(yōu)以下表現(xiàn)不佳的select語句的性能：

調(diào)優(yōu)查詢性能的最佳方法是研究該查詢的SQL執(zhí)行計劃。執(zhí)行前面的查詢：

從生成的計劃中可以清楚地看出，SQL Server引擎掃描所有表行(100K 記錄)以檢索請求的數(shù)據(jù)(1 條記錄)。從三個跡象可以看出這一點：
·表掃描運算符
·該運算符的高成本
·以及從將數(shù)據(jù)從表掃描流到下一個運算符的粗箭頭轉(zhuǎn)換到流輸出數(shù)據(jù)的細(xì)箭頭。

使用ApexSQL Plan，可以檢查查詢的執(zhí)行統(tǒng)計信息，例如該查詢的讀次數(shù)、持續(xù)時間和CPU成本，如下所示：

從計劃中得出的三個標(biāo)志將我們引向查詢性能不佳的主要原因，即EMP_Salary表中沒有索引，索引可以加快從該表中檢索數(shù)據(jù)的過程。我們將繼續(xù)使用下面的create INDEX語句在EMP_Salary表的EMP_ID列上創(chuàng)建索引：

…然后運行相同的語句。

從生成的執(zhí)行計劃中可以看出，SQL Server Engine會直接在創(chuàng)建的索引中尋找請求的數(shù)據(jù)，無需掃描整個底層表，Index Seek的成本降低到50%。此外，從Index Seek運算符流向下一個運算符的記錄數(shù)明顯減少，從箭頭的粗細(xì)可以看出，如下圖所示：

檢查執(zhí)行計劃的統(tǒng)計信息，將看到行數(shù)如何減少到2，而持續(xù)時間和CPU成本可以忽略不計，如下所示：

如果深入查看之前的計劃，你會發(fā)現(xiàn)另一個性能問題的跡象，即額外昂貴的RID查找和嵌套循環(huán)運算符。SQL Server引擎使用非聚集索引檢索EMP_ID列并返回基礎(chǔ)表以檢索其余列。這個問題可以通過創(chuàng)建一個覆蓋索引來解決，它允許SQL Server引擎從該有序的索引中檢索所有列，而無需檢查基礎(chǔ)表。

下面的create INDEX語句可用于為該查詢創(chuàng)建覆蓋索引：

運行相同的select語句，將看到不再出現(xiàn)RID Lookup和Nested Loops運算符，因為SQL Server引擎在索引中找到了所有請求的數(shù)據(jù)，如下所示：

調(diào)優(yōu)復(fù)雜查詢

我們看到了SQL執(zhí)行計劃如何幫助我們調(diào)優(yōu)簡單查詢的性能。它會以同樣的方式幫助我們進(jìn)行更復(fù)雜的查詢的調(diào)優(yōu)嗎？

讓我們刪除在EMP_Salaries表上創(chuàng)建的索引：

假設(shè)我們需要調(diào)整以下查詢的性能，該查詢連接之前創(chuàng)建的兩個EMP測試表，以檢索員工的信息：

如果執(zhí)行查詢，你會從生成的計劃中看到一些性能問題的跡象，比如Table Scan運算符，由于掃描了整個底層表；粗箭頭，由于大量的行在運算符之間流動以及額外昂貴的運算符，例如Hash Match運算符，如下面的SQL執(zhí)行計劃所示：

查看查詢的執(zhí)行統(tǒng)計，會看到讀取次數(shù)多，持續(xù)時間長，CPU消耗高，如下圖：

在執(zhí)行計劃的上半部分，將看到一條綠色的create INDEX語句，用于推薦的索引，這將提高查詢的性能，如下所示：

如果我們創(chuàng)建了建議的索引，那么再次執(zhí)行語句。生成的SQL執(zhí)行計劃將顯示，Table Scan運算符更改為Index Seek運算符。但是箭頭仍然是粗的，這是正常的行為，因為沒有從粗箭頭到細(xì)箭頭的過渡，如下所示：

執(zhí)行持續(xù)時間和CPU 成本的有點降低了，如下查詢的執(zhí)行統(tǒng)計所示：

可以通過更好的方式編寫查詢來實現(xiàn)查詢性能的增強(qiáng)。例如，可以使用限制返回行數(shù)的TOP子句來減小箭頭的粗細(xì)。另一方面，可以通過使用以下create INDEX語句在EMP_Salaries表上創(chuàng)建新索引來刪除過濾器運算符：

而生成的執(zhí)行計劃，經(jīng)過這些修改后，將是這樣的：

查看原文