導(dǎo)讀：
　　優(yōu)化數(shù)據(jù)庫服務(wù)器時(shí)，您需要優(yōu)化個(gè)人查詢性能。這與優(yōu)化服務(wù)器安裝的其他影響硬件和軟件配置等性能的方面一樣重要 — 甚至更為重要。
　　即使數(shù)據(jù)庫服務(wù)器是在功能最強(qiáng)大的硬件上運(yùn)行，它的性能還是可能會(huì)因?yàn)橐恍┬袨殄e(cuò)誤的查詢而受到負(fù)面影響。實(shí)際上，只要有一個(gè)壞的查詢（有時(shí)稱為“失控查詢”），就可能導(dǎo)致數(shù)據(jù)庫出現(xiàn)嚴(yán)重的性能問題。
　　反之，通過優(yōu)化一組成本最高或最常執(zhí)行的查詢，可以極大地提高數(shù)據(jù)庫的整體性能。在本文中，我將探討一些技術(shù)，您可使用這些技術(shù)識(shí)別并優(yōu)化服務(wù)器上成本最高和性能最壞的查詢。

分析執(zhí)行計(jì)劃
　　優(yōu)化個(gè)人查詢時(shí)，通常通過查看查詢的執(zhí)行計(jì)劃開始。此執(zhí)行計(jì)劃描述 SQL ServerTM為滿足查詢和生成所需結(jié)果集而執(zhí)行的物理和邏輯操作的順序。此執(zhí)行計(jì)劃是在查詢處理的最優(yōu)化階段由稱為查詢優(yōu)化器的數(shù)據(jù)庫引擎組件生成的，這要考慮到許多不同的因素，例如，查詢中使用的搜索謂詞、涉及的表和其連接條件、返回的列清單，以及是否存在能用作數(shù)據(jù)的有效訪問路徑的有用索引。
　　對(duì)于復(fù)雜的查詢，所有可能排列的數(shù)量可能非常大，因此查詢優(yōu)化器不評(píng)估所有的可能性，而是嘗試查找對(duì)于給定查詢“足夠好”的計(jì)劃。這是因?yàn)椴⒉豢偰懿檎彝昝烙?jì)劃；即便可能，評(píng)估所有可能性以查找完美計(jì)劃的開銷與所獲得的性能改進(jìn)相比起來，也很可能會(huì)得不償失。從 DBA觀點(diǎn)來看，了解其過程和局限性很重要。
　　有許多方法可用于檢索查詢的執(zhí)行計(jì)劃：
　　Management Studio 提供顯示實(shí)際執(zhí)行計(jì)劃和顯示估計(jì)執(zhí)行計(jì)劃等功能，這將用圖形方式來呈現(xiàn)計(jì)劃。這些功能為直接檢查提供了最適合的解決方案，是目前最常用的顯示和分析執(zhí)行計(jì)劃的方法（在本文中，我將使用以這種方式生成的圖表計(jì)劃來說明我的示例）。
　　各種 SET 選項(xiàng)，例如 SHOWPLAN_XML 和 SHOWPLAN_ALL，會(huì)以 XML 文檔或行集的形式返回執(zhí)行計(jì)劃，XML 文檔使用特殊架構(gòu)描述計(jì)劃，行集中則包含對(duì)執(zhí)行計(jì)劃中的每個(gè)操作的文字說明。
　　SQL Server Profiler 事件類，例如 Showplan XML，允許您收集跟蹤所收集語句的執(zhí)行計(jì)劃。
　　雖然 XML形式的執(zhí)行計(jì)劃可能不是人們最容易讀懂的格式，但此選項(xiàng)允許您編寫能分析執(zhí)行計(jì)劃的步驟和實(shí)用程序，以查找性能問題的跡象及不夠理想的計(jì)劃。基于 XML 的表示也可保存到具有 .sqlplan 擴(kuò)展名的文件中，然后在 Management Studio中打開以生成圖形表示形式。還可以保存這些文件以稍后供分析使用，當(dāng)然，這樣就不用在每次想要分析時(shí)重新生成執(zhí)行計(jì)劃。當(dāng)您希望比較計(jì)劃來查看計(jì)劃隨時(shí)間的變化情況時(shí)，這尤其有用。
估計(jì)的執(zhí)行開銷
　　對(duì)于執(zhí)行計(jì)劃，首先您需要了解它們是如何生成的。SQL Server使用基于開銷的查詢優(yōu)化器，也就是說，它會(huì)試圖使用最低的估計(jì)開銷來生成執(zhí)行計(jì)劃。該估計(jì)值是根據(jù)優(yōu)化器評(píng)估查詢所涉及的每個(gè)表時(shí)，提供給優(yōu)化器的數(shù)據(jù)分發(fā)統(tǒng)計(jì)資料得到的。如果那些統(tǒng)計(jì)資料丟失或過期，查詢優(yōu)化器將缺少查詢優(yōu)化過程所需的重要信息，因而可能會(huì)得到錯(cuò)誤的估計(jì)值。在這類情況下，優(yōu)化器可能會(huì)由于高估或低估不同計(jì)劃的執(zhí)行開銷而選擇不太理想的計(jì)劃。
　　對(duì)于估計(jì)的執(zhí)行開銷，有一些常見的錯(cuò)誤假定。特別是，人們常常假設(shè)估計(jì)的執(zhí)行開銷能夠很好地指示查詢需花多長時(shí)間執(zhí)行，而該估計(jì)值能讓您分出好的計(jì)劃和壞的計(jì)劃。實(shí)際情況并不是這樣。首先，表達(dá)估計(jì)開銷采用什么單位以及它們是否與執(zhí)行時(shí)間有直接關(guān)聯(lián)都已記錄得相當(dāng)清楚。其次，由于這只是一個(gè)估計(jì)值，且可能并不正確，因此，在 CPU、I/O和執(zhí)行時(shí)間方面，有時(shí)候，盡管具有較高估計(jì)開銷的估計(jì)值高一些，但效率反而比較高。這通常發(fā)生在涉及表變量的查詢中 —因?yàn)闆]有統(tǒng)計(jì)數(shù)據(jù)可用于表變量，即使表變量中包含許多行，查詢優(yōu)化器都始終假設(shè)表變量中僅包含一行。因而，查詢優(yōu)化器會(huì)基于不準(zhǔn)確的估計(jì)值選擇計(jì)劃。因此，比較各查詢的執(zhí)行計(jì)劃時(shí)，不應(yīng)只依賴估計(jì)的查詢開銷，而應(yīng)在分析中包含 STATISTICS I/O 和 STATISTICS TIME選項(xiàng)輸出結(jié)果，以了解 I/O 和 CPU 時(shí)間方面的實(shí)際執(zhí)行開銷。
　　在此，有個(gè)稱為并行計(jì)劃的特殊類型的執(zhí)行計(jì)劃值得一提。如果您在具有多個(gè) CPU的服務(wù)器上運(yùn)行查詢，并且您的查詢符合并行執(zhí)行的條件，則可以選擇使用并行計(jì)劃（通常，查詢優(yōu)化器只對(duì)其開銷超出特定的可配置閾值的查詢考慮使用并行計(jì)劃）。由于管理多個(gè)并行執(zhí)行的線程（指跨線程分發(fā)任務(wù)、執(zhí)行同步以及收集結(jié)果）會(huì)產(chǎn)生開銷，因此執(zhí)行并行計(jì)劃開銷更大，這會(huì)在估計(jì)開銷中有所體現(xiàn)。那么，為什么并行計(jì)劃比較為便宜的非并行計(jì)劃更受歡迎呢？這是因?yàn)槎鄠€(gè) CPU的處理能力發(fā)揮了威力，并行計(jì)劃得出結(jié)果的速度往往比標(biāo)準(zhǔn)計(jì)劃更快。根據(jù)您的特定方案，包括來自其他查詢的可用資源和并行負(fù)載一類的變量，此情形可能正是您的設(shè)置所期望的。如果真是這樣，您應(yīng)控制哪些查詢能夠生成并行計(jì)劃，以及每個(gè)查詢有多少 CPU可供利用。通過在服務(wù)器級(jí)別設(shè)置最大并行度選項(xiàng)，然后根據(jù)需要在單個(gè)查詢級(jí)別使用 OPTION (MAXDOP n) 覆蓋它，即可達(dá)到此目的。
分析執(zhí)行計(jì)劃
　　現(xiàn)在，我要讓大家看一個(gè)簡單的查詢以及該查詢的執(zhí)行計(jì)劃和改進(jìn)其性能的一些方法。假設(shè)我使用 Management Studio 執(zhí)行查詢，并在 SQL Server 2005 上的 Adventure Works 示例數(shù)據(jù)庫中啟用了“包括實(shí)際的執(zhí)行計(jì)劃”選項(xiàng)：
　　SELECT c.CustomerID, SUM(LineTotal)
　　FROM Sales.SalesOrderDetail od
　　JOIN Sales.SalesOrderHeader oh
　　ON od.SalesOrderID=oh.SalesOrderID
　　JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
　　GROUP BY c.CustomerID
　　結(jié)果，我看到了圖 1中所述的執(zhí)行計(jì)劃。此示例查詢計(jì)算每個(gè) Adventure Works客戶發(fā)出的訂單總數(shù)。看一下這個(gè)執(zhí)行計(jì)劃，您會(huì)看到數(shù)據(jù)庫引擎是如何處理查詢并生成結(jié)果的。應(yīng)按從上到下、從左到右的順序閱讀圖形執(zhí)行計(jì)劃。每個(gè)圖標(biāo)都代表一個(gè)執(zhí)行的邏輯和物理操作，箭頭指示操作之間的數(shù)據(jù)流向。箭頭厚度代表操作之間傳遞的行數(shù)，箭頭越厚，包含的行數(shù)越多。如果將指針放在其中一個(gè)運(yùn)算符圖標(biāo)上，會(huì)在黃色的工具提示（如圖 2所示）中顯示此具體操作的詳細(xì)信息。

　　???

圖 1 執(zhí)行計(jì)劃示例 (單擊該圖像獲得較小視圖)



圖 2 操作詳細(xì)信息 (單擊該圖像獲得較小視圖)
　　通過查看每個(gè)運(yùn)算符，可以分析所執(zhí)行步驟的順序：
　　數(shù)據(jù)庫引擎對(duì) Sales.Customer 表執(zhí)行聚集索引掃描操作，然后返回該表中所有行的 CustomerID 列。
　　然后它對(duì) Sales.SalesOrderHeader 表中的一個(gè)索引執(zhí)行索引掃描（指非聚集索引掃描）。這是 CustomerID 列上的一個(gè)索引，但在其中也暗含了 SalesOrderID 列（表聚集鍵）。掃描會(huì)同時(shí)返回這兩列中的值。
　　來自兩個(gè)掃描的輸出都使用“合并聯(lián)接”物理運(yùn)算符聯(lián)接到 CustomerID列（這是執(zhí)行邏輯聯(lián)接操作的三種可用物理方法中的一種。此方法速度很快，但需要在聯(lián)接的列上對(duì)這兩個(gè)輸入進(jìn)行排序。在本例中，兩個(gè)掃描操作均已返回在 CustomerID 排序的行，因此無需另外執(zhí)行排序操作）。
　　接下來，數(shù)據(jù)庫引擎對(duì) Sales.SalesOrderDetail表上的聚集索引執(zhí)行掃描，從此表內(nèi)的所有行中檢索四列（SalesOrderID、OrderQty、UnitPrice 和 UnitPriceDiscount）的值（估計(jì)此操作將返回 123、317 行，而實(shí)際上也確實(shí)如此，您可以從圖 2中的“估計(jì)行數(shù)”和“實(shí)際行數(shù)”屬性中看到。因此，該估計(jì)非常準(zhǔn)確）。
　　聚集索引掃描生成的行將傳遞到第一個(gè)“計(jì)算標(biāo)量”運(yùn)算符，這樣，根據(jù)公式中涉及的 OrderQty、UnitPrice 和 UnitPriceDiscount 列，即可計(jì)算出每行的計(jì)算列 LineTotal 的值。
　　根據(jù)計(jì)算列公式的需要，第二個(gè)“計(jì)算標(biāo)量”運(yùn)算符將對(duì)上一計(jì)算的結(jié)果應(yīng)用 ISNULL 函數(shù)。這樣就完成了對(duì) LineTotal 列的計(jì)算，并將計(jì)算結(jié)果連同 SalesOrderID 列一起返回到下一運(yùn)算符。
　　通過使用“哈希匹配”物理運(yùn)算符，聯(lián)接步驟 3 中“合并聯(lián)接”運(yùn)算符的輸出內(nèi)容與步驟 6 中“計(jì)算標(biāo)量”運(yùn)算符的輸出內(nèi)容。
　　然后，對(duì)由 CustomerID 列值和計(jì)算所得的 LineTotal 列的 SUM 合計(jì)從“合并聯(lián)接”返回的行組應(yīng)用另一個(gè)“哈希匹配”運(yùn)算符。
　　最后一個(gè)節(jié)點(diǎn) SELECT 既不是物理運(yùn)算符也不是邏輯運(yùn)算符，而是一個(gè)占位符，用以表示總計(jì)查詢結(jié)果和開銷。
　　在我的便攜式計(jì)算機(jī)上，此執(zhí)行計(jì)劃的估計(jì)開銷是 3,31365（如圖 3所示）。如果在 STATISTICS I/O 處于 ON 狀態(tài)時(shí)執(zhí)行此計(jì)劃，查詢報(bào)告對(duì)涉及的三個(gè)表執(zhí)行了共計(jì) 1,388 個(gè)邏輯讀取操作。每個(gè)運(yùn)算符下顯示的百分比表示與整個(gè)執(zhí)行計(jì)劃的總體估計(jì)開銷相關(guān)的每個(gè)單個(gè)運(yùn)算符的開銷。看一下圖 1中的計(jì)劃，可以看出整個(gè)執(zhí)行計(jì)劃的大部分總開銷都與以下三個(gè)運(yùn)算符相關(guān)聯(lián)：Sales.SalesOrderDetail 表的聚集索引掃描以及兩個(gè)哈希匹配運(yùn)算符。但在對(duì)其進(jìn)行優(yōu)化之前，我想指出我的查詢中的一個(gè)非常簡單的改動(dòng)，這一改動(dòng)將允許我同時(shí)消除兩個(gè)運(yùn)算符。



圖 3 查詢的總估計(jì)執(zhí)行開銷

　　由于我從 Sales.Customer 表中返回的只是 CustomerID 列，而此列又是 Sales.SalesOrderHeader 表中的外鍵，因此，我能夠使用以下代碼從查詢中完全消除生成的 Customer表，并且不必更改查詢所生成的邏輯意義或結(jié)果：
　　SELECT oh.CustomerID, SUM(LineTotal)
　　FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
　　ON od.SalesOrderID=oh.SalesOrderID
　　GROUP BY oh.CustomerID
　　這樣就產(chǎn)生了另一個(gè)執(zhí)行計(jì)劃，如圖 4所示。

圖 4 從查詢中去除了 Customer 表的執(zhí)行計(jì)劃 (單擊該圖像獲得較小視圖)
　　以下兩個(gè)操作被完全消除：Customer 表的聚集索引掃描以及 Customer 與 SalesOrderHeader 之間的合并聯(lián)接，并且哈希匹配聯(lián)接將由更高效的合并聯(lián)接取代。但是，為在 SalesOrderHeader 和 SalesOrderDetail 表之間使用“合并聯(lián)接”，必須返回經(jīng)過聯(lián)接列 SalesOrderID排序的兩個(gè)表中的所有行。為實(shí)現(xiàn)此目的，查詢優(yōu)化器決定對(duì) SalesOrderHeader表執(zhí)行聚集索引掃描，而不使用非聚集索引掃描，這樣在涉及的 I/O方面開銷較低。此示例很好地說明了查詢優(yōu)化器的實(shí)際工作原理：由于更改執(zhí)行聯(lián)接操作的物理方式所節(jié)省的開銷要比聚集索引掃描生成的附加 I/O開銷多，因此，查詢優(yōu)化器選擇得出的運(yùn)算符組合，因?yàn)樗a(chǎn)生的總估計(jì)執(zhí)行開銷可能會(huì)是最低的。在我的便攜式計(jì)算機(jī)上，盡管邏輯讀取數(shù)量上升了（已升至1,941），但所耗費(fèi)的 CPU 時(shí)間實(shí)際上卻少了，并且此查詢的估計(jì)執(zhí)行開銷也下降了大約 13％ (2,89548)。
　　假設(shè)我希望進(jìn)一步改進(jìn)此查詢的性能。現(xiàn)在我要看一下 SalesOrderHeader表的聚集索引掃描，此運(yùn)算符已成為該執(zhí)行計(jì)劃中開銷最大的運(yùn)算符了。由于我只需要使用此表中的兩列來填充查詢，因此我可以創(chuàng)建一個(gè)只包含這兩列的非聚集索引，這樣，即可通過對(duì)小得多的非聚集索引進(jìn)行掃描來替代對(duì)整個(gè)表的掃描。索引定義可能會(huì)如下所示：
　　CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
　　ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
　　請(qǐng)注意，我創(chuàng)建的索引包含一個(gè)計(jì)算列。并不一定總會(huì)這樣，具體情況取決于對(duì)計(jì)算列的定義。
　　創(chuàng)建此索引并執(zhí)行同樣的查詢后，我得到一個(gè)新的執(zhí)行計(jì)劃，如圖 5所示。

圖 5 優(yōu)化后的執(zhí)行計(jì)劃 (單擊該圖像獲得較小視圖)
　　對(duì) SalesOrderDetail表進(jìn)行的聚集索引掃描已被非聚集索引掃描取代，后者的 I/O 開銷要小得多。我還消除了其中的一個(gè)“計(jì)算標(biāo)量”運(yùn)算符，因?yàn)槲业乃饕邪延?jì)算出的 LineTotal 列的值。現(xiàn)在，估計(jì)執(zhí)行計(jì)劃開銷是 2,28112，并會(huì)在執(zhí)行查詢時(shí)進(jìn)行 1,125 次邏輯讀取。
覆蓋索引

　　我在 SalesOrderDetail上創(chuàng)建的索引是所謂的“覆蓋索引”的一個(gè)示例。它是一個(gè)包含填充查詢所需的所有列的非聚集索引，無需使用表掃描運(yùn)算符或聚集索引掃描運(yùn)算符掃描整個(gè)表。此索引實(shí)際上是表的一個(gè)小型副本，包含該表中所有列的一個(gè)子集。只有需要響應(yīng)查詢的那些列才包含在該索引中，換句話說，該索引僅包含需要“覆蓋”查詢的列。
　　為最常執(zhí)行的查詢創(chuàng)建覆蓋索引是查詢優(yōu)化中使用的最簡單最常見的一種技術(shù)。當(dāng)表中包含很多列，但查詢最常引用的只有很少幾列時(shí)，此類索引尤其適用。通過創(chuàng)建一個(gè)或多個(gè)覆蓋索引，可以大大改進(jìn)受影響的查詢的性能，因?yàn)檫@些索引要訪問的數(shù)據(jù)量小得多，從而使產(chǎn)生的 I/O開銷更少。但在執(zhí)行數(shù)據(jù)修改操作（插入、更新和刪除）期間，還存在維護(hù)附加索引所需的隱含開銷。您應(yīng)根據(jù)您的環(huán)境以及 SELECT查詢與數(shù)據(jù)修改之間的比例，仔細(xì)判斷此附加索引的維護(hù)開銷相對(duì)于查詢性能的改進(jìn)是否值得。
　　不必害怕創(chuàng)建多列索引（相對(duì)于單列索引而言）。多列索引往往比單列索引有用得多，查詢優(yōu)化器更有可能使用它們來覆蓋查詢。大多數(shù)的覆蓋索引都是多列索引。
　　在我的示例查詢中，仍然有改進(jìn)的余地，將覆蓋索引置于 SalesOrderHeader表中可以進(jìn)一步優(yōu)化此查詢。這將消除聚集索引掃描，而采用非聚集索引掃描。我將此留給您進(jìn)行練習(xí)。請(qǐng)嘗試給出索引定義 —要成為此查詢的覆蓋索引，應(yīng)包含哪些列，以及索引定義中的列順序?qū)π阅苁欠裼胁煌绊憽Ｒ榭唇獯穑?qǐng)參見“客戶訂單查詢練習(xí)”邊欄。
　　索引視圖
　　如果我的示例查詢的性能非常重要，我可以多執(zhí)行一個(gè)步驟來創(chuàng)建可實(shí)際存儲(chǔ)查詢的具體結(jié)果的索引視圖。索引視圖存在某些先決條件和限制，但如果能使用索引視圖，可以顯著改善性能。請(qǐng)記住，與標(biāo)準(zhǔn)索引相比，索引視圖需要的維護(hù)開銷較高。因此，應(yīng)仔細(xì)斟酌在何時(shí)使用索引視圖。在本例中，索引定義如下所示：
　　CREATE VIEW vTotalCustomerOrders
　　WITH SCHEMABINDING
　　AS
　　SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
　　FROM Sales.SalesOrderDetail od
　　JOIN Sales.SalesOrderHeader oh
　　ON od.SalesOrderID=oh.SalesOrderID
　　GROUP BY oh.CustomerID
　　請(qǐng)注意 WITH SCHEMABINDING 選項(xiàng)，此選項(xiàng)是在此類視圖上創(chuàng)建索引的先決條件；還要注意 COUNT_BIG(*) 函數(shù)，如果我們的索引定義中包含聚合函數(shù)（在此示例中是 SUM），則此函數(shù)是必需的。創(chuàng)建此視圖后，可以在其上創(chuàng)建一個(gè)索引，如下所示：
　　CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
　　ON vTotalCustomerOrders(CustomerID)
　　創(chuàng)建此索引時(shí)，包含在視圖定義中的查詢結(jié)果已具體化，并以索引形式實(shí)際存儲(chǔ)在磁盤中。請(qǐng)注意，對(duì)基礎(chǔ)表執(zhí)行的所有數(shù)據(jù)修改操作接著會(huì)根據(jù)其定義自動(dòng)更新視圖中的值。
　　如果我現(xiàn)在返回查詢，會(huì)產(chǎn)生什么結(jié)果取決于我運(yùn)行的 SQL Server 版本。在 Enterprise Edition 或 Developer Edition 中，查詢優(yōu)化器會(huì)自動(dòng)將此查詢與索引視圖定義匹配，并使用索引視圖，而不是查詢所涉及的基表。圖 6顯示了本示例中生成的執(zhí)行計(jì)劃。此計(jì)劃僅由一個(gè)操作組成：對(duì)我在視圖上創(chuàng)建的索引進(jìn)行聚集索引掃描。估計(jì)執(zhí)行開銷僅為 0,09023，并且只執(zhí)行 92 次邏輯讀取。

圖 6 使用索引視圖時(shí)的執(zhí)行計(jì)劃 (單擊該圖像獲得較小視圖)
　　在 SQL Server 的其他版本中，仍然可以創(chuàng)建并使用此索引視圖，但為達(dá)到同樣的效果，必須使用 NOEXPAND 提示將查詢更改為直接參考該視圖，如下所示：
　　SELECT CustomerID, OrdersTotalAmt
　　FROM vTotalCustomerOrders WITH (NOEXPAND)
　　您可以看到，如果使用得當(dāng)，索引視圖可以成為一項(xiàng)非常強(qiáng)大的功能。它們?cè)趦?yōu)化對(duì)大量數(shù)據(jù)進(jìn)行聚合的查詢時(shí)最為有用。如果用在 Enterprise Edition 中，這些視圖對(duì)許多查詢都有用，并且不要求更改代碼。
識(shí)別要優(yōu)化的查詢
　　我怎樣識(shí)別值得優(yōu)化的查詢？我要查找執(zhí)行得最為頻繁的查詢，單獨(dú)執(zhí)行這些查詢的開銷可能并不高，但執(zhí)行這些查詢的總計(jì)開銷可能要比很少執(zhí)行的大型查詢的開銷高得多。我并不是說您不應(yīng)該優(yōu)化大型查詢，只是覺得應(yīng)先關(guān)注最常執(zhí)行的查詢。那么，您如何識(shí)別這些查詢呢？
　　遺憾的是，最可靠的方法有點(diǎn)復(fù)雜，涉及到跟蹤對(duì)您的服務(wù)器執(zhí)行的所有查詢，然后根據(jù)其簽名進(jìn)行分組（即，帶有實(shí)際參數(shù)值的查詢文本將由占位符取代，以識(shí)別相同的查詢類型，即便查詢是使用不同的參數(shù)值執(zhí)行的也一樣）。這是一個(gè)復(fù)雜的過程，因?yàn)椴樵兒灻茈y生成。Itzik Ben-Gan在其《Microsoft SQL Server 2005: T-SQL Querying》一書中介紹了一種解決方案，此解決方案使用 CLR用戶定義的函數(shù)和正則表達(dá)式。
　　還有一種比較簡單的方法，但可靠性較差。您可以依賴在執(zhí)行計(jì)劃緩存中為所有查詢保留的統(tǒng)計(jì)數(shù)據(jù)，并使用動(dòng)態(tài)管理視圖查詢這些數(shù)據(jù)。圖 7中包含一個(gè)示例查詢，此示例向您顯示緩存中累計(jì)邏輯讀取次數(shù)最高的 20個(gè)查詢的文本和執(zhí)行計(jì)劃。對(duì)于快速識(shí)別會(huì)產(chǎn)生最高邏輯讀取次數(shù)的查詢而言，此查詢非常便利，但也存在一些限制。即，此查詢只顯示在運(yùn)行查詢時(shí)緩存了其計(jì)劃的那些查詢。如果有未緩存的內(nèi)容，這些內(nèi)容就會(huì)丟失。
　　識(shí)別這些拙劣的查詢后，您可以查看其查詢計(jì)劃，并利用我在本文中介紹的一些索引技術(shù)來尋找改進(jìn)其性能的方法。如果能夠成功完成，表示您的時(shí)間沒有白費(fèi)。
　　快樂優(yōu)化！


Maciej Pilecki 是 Solid Quality Mentors 的準(zhǔn)顧問，這是一家專門致力于培訓(xùn)、指導(dǎo)和咨詢的全球性組織。他是 Microsoft 認(rèn)證培訓(xùn)師 (MCT) 和 SQL Server 最有價(jià)值專家 (MVP)，并經(jīng)常講授關(guān)于 SQL Server 和應(yīng)用程序開發(fā)的諸多方面的課程并在討論此類內(nèi)容的會(huì)議上講話。

本文轉(zhuǎn)自
http://idoall.org/blogs/ian/archive/2007/11/14/sql-server.aspx

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1920782