SQL Server 遞增鍵統計資訊問題：從追蹤旗標到新版基數估計的演進

當查詢條件落在統計資訊直方圖的最後一步之後（即所謂「遞增鍵」或「上升鍵」問題），舊版 SQL Server 基數估計器會預設估計 1 筆資料，導致嚴重的執行計畫偏差。本文詳細重現問題場景，對比 SQL Server 2005 SP1 ~ 2012 的追蹤旗標解法，與 SQL Server 2014 新版基數估計器的原生改善。

問題重現：直方圖邊界外的查詢

建立叢集索引於 OrderDate，重建索引更新統計資訊後，直方圖最大值為 2008-07-31。隨後插入 200 筆 2010-01-01 之後的資料，這些資料落在直方圖範圍之外。

DBCC SHOW_STATISTICS('dbo.Orders', 'idx_CI') WITH HISTOGRAM

查詢 WHERE OrderDate = '2010-01-01' 時，舊版估計器回傳估計 1 筆：

SQL Server 2005 SP1 ~ 2012：追蹤旗標 2388/2389

機制：連續 3 次以「遞增鍵值」更新統計資訊後，該欄位會被標記為 Ascending。需啟用 TF 2388 觀察標記，TF 2389 啟用密度向量估計。

1. DBCC TRACEON(2388); DBCC SHOW_STATISTICS(...) 觀察 Leading Column Type 欄位變為 Ascending。
2. 連續 3 次 UPDATE STATISTICS ... WITH FULLSCAN 並插入遞增資料。
3. 啟用 TF 2389 查詢：OPTION (RECOMPILE, QUERYTRACEON 2389)，估計器改用密度向量，估計行數 = 密度 × (總行數 - 直方圖範圍內行數)。

作者註：實測 SQL Server 2008 R2 仍估計 1，原因未明，歡迎讀者補充。

SQL Server 2014：新版基數估計器原生支援

新估計器（相容性層級 120+）預設針對直方圖邊界外的遞增鍵查詢，自動使用密度向量估計，**無需追蹤旗標** 。等效於舊版的 TF 2389 行為。可用 TF 2312 強制啟用新估計器驗證：

SELECT * FROM Orders WHERE OrderDate = '20100401' OPTION (RECOMPILE, QUERYTRACEON 2312)

估計行數同為 28.4516，但不需手動標記 Ascending，大幅簡化維運。

作者註：實測 2014 仍估計 1，可能涉及相容性層級或統計資訊更新時機，需進一步驗證。

最佳實務建議

• **SQL Server 2014+**：確保資料庫相容性層級 >= 120，享受原生改善；定期更新統計資訊（AUTO_UPDATE_STATISTICS ON）。
• **舊版本**：啟用 TF 2389 為執行個體級預設，或查詢層級加 QUERYTRACEON 2389；建立維護計畫定期 UPDATE STATISTICS WITH FULLSCAN 觸發 Ascending 標記。
• **通用**：避免單調遞增鍵成為叢集索引鍵（如改用 SEQUENCE、GUID 或雜湊分割），從根源消除問題。

總結

遞增鍵問題是統計資訊直方圖固有侷限。舊版依賴 TF 2388/2389 手動干預，新版基數估計器內建智慧偵測與密度向量回退，顯著降低維運複雜度。升級相容性層級是徹底解決的最佳路徑。