在眾多數據庫當中，SQL Server是我們比較常見的數據庫。因此對于許多新手來說，對于SQL Server數據庫查詢優化器如何工作并不清楚。SQL Server 數據庫引擎的核心是兩個主要組件：存儲引擎和查詢處理器（也稱為關系引擎）。存儲引擎：以優化并發性并同時保持數據完整性的方式照顧磁盤和內存之間的數據讀取。查詢處理器：1.負責通過Query Optimizer設計查詢計劃;2.由Execution Engine根據該計劃執行查詢。

　　查詢處理器執行以下操作：

1.查詢解析

2.將查詢綁定到對象

3.生成可能的執行計劃

4.每個計劃的成本評估

　　執行引擎執行以下操作：

1.查詢執行

2.計劃緩存

解析將SQL查詢轉換為初始樹表示形式。綁定主要涉及名稱解析。

　　搜索空間

我們將給定查詢的搜索空間定義為該查詢的所有可能執行計劃的集合，并且該搜索空間中的任何可能計劃都返回相同的結果。

　　生成候選人執行計劃

如前所述，查詢優化器的基本目的是為您的查詢找到有效的執行計劃。即使對于相對簡單的查詢，也可能有很多不同的方法來訪問數據以產生相同的最終結果。因此，查詢優化器必須從可能的大量候選執行計劃中選擇最佳的計劃，并且做出明智的選擇非常重要，因為將結果返回給用戶的時間可能會有所不同瘋狂，取決于選擇哪個計劃。

查詢優化器必須在優化時間和計劃質量之間取得平衡。SQL Server不會進行詳盡的搜索，而是嘗試盡快找到合適的有效計劃。

　　評估每個計劃的成本

查詢優化器需要估算這些計劃的成本，然后選擇成本最低的計劃。為了估算計劃的成本，它使用考慮了I / O，CPU和內存等資源使用的成本核算公式來估算該計劃中每個物理操作員的成本。

基數估計：查詢計劃的成本估計主要取決于物理操作員使用的算法以及估計需要處理的記錄數;記錄數量的這種估計稱為基數估計。

　　查詢執行和計劃緩存

優化查詢后，執行引擎將使用生成的計劃來檢索所需的數據。生成的執行計劃可以存儲在內存中，在計劃緩存中，以便在再次執行同一查詢時可以重新使用它。

但是，對于給定查詢，重用現有計劃可能并不總是最佳解決方案。根據表中數據的分布，給定查詢的最佳執行計劃可能會根據所述查詢中提供的參數而有很大差異，并且稱為參數嗅探的行為可能會導致選擇次優計劃。

即使執行計劃在計劃緩存中可用，某些元數據更改或對數據庫內容所做的足夠大的更改也可能使現有計劃無效或次優，從而導致現有計劃無效從計劃緩存中丟棄并生成新的優化。

　　重新編譯

您可以強制SQL Server每次運行時重新編譯存儲過程。這樣做的好處是，每次運行時都會創建最佳查詢計劃。但是，重新編譯是占用大量CPU的操作。對于經常運行的存儲過程或在已經受到CPU資源限制的服務器上，這可能不是理想的解決方案。要記住的另一件事是，這些計劃不會存儲在緩存中，這使它們更難找到是否有問題。

ALTER PROCEDURE Get_OrderID_OrderQty

@ProductID INT

WITH RECOMPILE

AS

SELECT SalesOrderDetailID, OrderQty

FROM Sales.SalesOrderDetail

WHERE ProductID = @ProductID;

提示

另一個選擇是使用OPTIMIZE FOR查詢提示。這告訴SQL Server在編譯計劃時使用指定的值。如果通過測試可以找到每次生成“足夠好的”計劃的值，并且鼠標和大象的性能都可以接受，那么這對您來說是一個不錯的選擇。

但是，請了解您正在引導查詢優化器。您說的是您的最佳想法。OPTIMIZE FOR的最大缺點在于數據分布發生變化的表。更改速度越快，此提示可能會過時。如果您提供的價值在一個月或一年中不是最優的，該怎么辦?您需要有一種定期檢查和修訂此方法的方法。

ALTER PROCEDURE Get_OrderID_OrderQty

@ProductID INT

AS

SELECT SalesOrderDetailID, OrderQty

FROM Sales.SalesOrderDetail

WHERE ProductID = @ProductID

OPTION (OPTIMIZE FOR (@ProductID=945));

現實情況是，即使經過30多年的研究，查詢優化器還是非常復雜的軟件，仍然面臨一些技術挑戰。結果，即使在為Query Optimizer提供了所需的所有信息之后，甚至在似乎沒有任何明顯問題的情況下，您仍然可能無法獲得有效的計劃。

通過上述介紹，SQL Server查詢優化器如何工作相信大家已經清楚了吧，想了解更多關于SQL Server數據庫信息，請繼續關注中培偉業。