作為一個DBA，排除SQL Server問題是我們的職責之一，每個月都有很多人給我們帶來各種不能解釋卻要解決的性能問題。我就多次聽到，以前的SQL Server的性能問題都還好且在正常範圍內，但現在一切已經改變，SQL Server開始糟糕，瘋狂的事情不能解釋。在這個情況下我介入，分析下整個SQL...

作為一個DBA，排除SQL Server問題是我們的職責之一，每個月都有很多人給我們帶來各種不能解釋卻要解決的性能問題。

我就多次聽到，以前的SQL Server的性能問題都還好且在正常範圍內，但現在一切已經改變，SQL Server開始糟糕，瘋狂的事情不能解釋。在這個情況下我介入，分析下整個SQL Server的安裝，最後用一些神奇的調查方法找出性能問題的根源。

但很多時候問題的根源是一樣的：所謂的計劃回歸（Plan Regression），即特定查詢的執行計劃已經改變。昨天SQL Server已經緩存了在計劃緩存里緩存了一個好的執行計劃，今天就生成、緩存最後重用了一個糟糕的執行計劃——不斷重覆。

進入SQL Server 2016後，我就變得有點多餘了，以為微軟引進了查詢存儲（Query Store）。這是這個版本最熱門的功能！查詢存儲幫助你很容易找出你的性能問題是不是計劃回歸造成的。如果你找到了計劃回歸，這很容易強制一個特定計劃不使用計劃嚮導。聽起來很有意思？讓我們通過一個特定的場景，向你展示下在SQL Server 2016里，如何使用查詢存儲來找出並最終修正計劃回歸。

查詢存儲（Query Store）——我的對手

在SQL Server 2016里，在你使用查詢存儲功能前，你要對這個資料庫啟用它。這是通過ALTER DATABASE語句實現，如你所見的下列代碼：

 1 CREATE DATABASE QueryStoreDemo
 2 GO
 3 
 4 USE QueryStoreDemo
 5 GO
 6 
 7 -- Enable the Query Store for our database
 8 ALTER DATABASE QueryStoreDemo
 9 SET QUERY_STORE = ON
10 GO
11 
12 -- Configure the Query Store
13 ALTER DATABASE QueryStoreDemo SET QUERY_STORE
14 (
15     OPERATION_MODE = READ_WRITE, 
16     CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 367), 
17     DATA_FLUSH_INTERVAL_SECONDS = 900, 
18     INTERVAL_LENGTH_MINUTES = 1, 
19     MAX_STORAGE_SIZE_MB = 100, 
20     QUERY_CAPTURE_MODE = ALL, 
21     SIZE_BASED_CLEANUP_MODE = OFF
22 )
23 GO

線上幫助為你提供了各個選項的詳細信息。接下來我創建一個簡單的表，創建一個非聚集索引，最後插入80000條記錄。

 1 -- Create a new table
 2 CREATE TABLE Customers
 3 (
 4     CustomerID INT NOT NULL PRIMARY KEY CLUSTERED,
 5     CustomerName CHAR(10) NOT NULL,
 6     CustomerAddress CHAR(10) NOT NULL,
 7     Comments CHAR(5) NOT NULL,
 8     Value INT NOT NULL
 9 )
10 GO
11 
12 -- Create a supporting new Non-Clustered Index.
13 CREATE UNIQUE NONCLUSTERED INDEX idx_Test ON Customers(Value)
14 GO
15 
16 -- Insert 80000 records
17 DECLARE @i INT = 1
18 WHILE (@i <= 80000)
19 BEGIN
20     INSERT INTO Customers VALUES
21     (
22         @i,
23         CAST(@i AS CHAR(10)),
24         CAST(@i AS CHAR(10)),
25         CAST(@i AS CHAR(5)),
26         @i
27     )
28     
29     SET @i += 1
30 END
31 GO

為了訪問我們的表，我額創建了一個簡單的存儲過程，傳入value值作為過濾謂語。

 1 -- Create a simple stored procedure to retrieve the data
 2 CREATE PROCEDURE RetrieveCustomers
 3 (
 4     @Value INT
 5 )
 6 AS
 7 BEGIN
 8     SELECT * FROM Customers
 9     WHERE Value < @Value
10 END
11 GO

現在我用80000的參數值來執行存儲過程。

1 -- Execute the stored procedure.
2 -- This generates an execution plan with a Key Lookup (Clustered).
3 EXEC RetrieveCustomers 80000
4 GO

現在當你查看實際的執行計劃時，你會看到查詢優化器已經選擇了有419個邏輯讀的聚集索引掃描運算符。SQL Server並沒有使用非聚集索引，因為這樣沒有意義，由於臨界點。這個查詢結果並沒有選擇性。

現在假設SQL Server發生了些事情（例如重啟，故障轉移），SQL Server忽略已經緩存的計劃，這裡我通過執行DBCC FREEPROCCACHE從計劃緩存里抹掉每個緩存的計劃來模擬SQL Server重啟（不要在生產環境里使用！）。

1 -- Get rid of the cached execution plan...
2 DBCC FREEPROCCACHE
3 GO

現在有人再次調用你的存儲過程，這次輸入參數值是1。這次執行計劃不一樣，因為現在在執行計劃里你會有書簽查找。SQL Server估計行數是1，在非聚集索引里沒有找到任何行。因此與非聚集索引查找結合的書簽查找才有意義，因為這個查詢是有選擇性的。

現在我再執行用80000參數值的查詢。

1 -- Execute the stored procedure
2 EXEC RetrieveCustomers 1
3 GO
4 
5 -- Execute the stored procedure again
6 -- This introduces now a plan regression, because now we get a Clustered Index Scan
7 -- instead of the Key Lookup (Clustered).
8 EXEC RetrieveCustomers 80000
9 GO

當你再次看STATISTICS IO的輸出，你會看到這個查詢現在產生了160139個邏輯讀——剛纔的查詢只有419個邏輯讀。這個時候DBA的手機就會響起，性能問題。但今天我們要不同的方式解決——使用剛纔啟用的查詢存儲。

當你再次看實際的執行計劃，在你面前你會看到有一個計劃回歸，因為SQL Server剛重用了書簽查找的的計劃緩存。剛纔你有聚集索引掃描運算符的執行計劃。這是SQL Server里參數嗅探的副作用。

讓我們通過查詢存儲來詳細瞭解這個問題。在SSMS里的對象資源管理器里，SQL Server 2016提供了一個新的結點叫查詢存儲，這裡你會看到一些報表。

【前幾個資源使用查詢】向你展示了最昂貴的查詢，基於你選擇的維度。這裡切換到【邏輯讀取次數】。

這裡在你面前有一些查詢。最昂貴的查詢生成了近500000個邏輯讀。這是我們的初始語句。這已經是第一個WOW效果的的查詢存儲：SQL Server重啟後，查詢存儲的數據還是存在的！第2個是你存儲過程里的SELECT語句。在查詢存儲里每個捕獲的查詢都有一個標示號——這裡是7。最後當你看報告的右邊，你會看這個查詢的不同執行計劃。