在 SQL Server 2014 中，非常複雜的查詢突然需要 35 分鐘才能完成
我有一個非常複雜的查詢，在 SQL Server 2012 中產生正確的結果很慢但沒問題。升級到 SQL Server 2014 並將數據庫的兼容模式設置為 2014 (120) 後，突然需要 35 分鐘才能完成。我已經在 SQL Server 2014 上上傳了實際計劃。
兼容級別為 120 的 SQL Server 2014 使用新的 CE。SQL Server 2012 使用舊版 CE。新的 CE 使用完全不同的模型進行基數估計，Microsoft 預計該模型可以為大多數工作負載帶來更好的查詢性能。但是，他們承認某些工作負載或查詢在使用新 CE 時可能會執行得更差。這可能就是你所處的情況。
在調查完成速度不夠快的查詢時，我嘗試確定的第一件事是查詢速度慢的原因。您的查詢很慢，因為從單個索引查找運算符讀取了超過 40 億行：
您可以通過查看在操作員級別顯示的實際時間統計資訊來驗證這是查詢中最昂貴的部分。索引查找使用了 222360 毫秒的 CPU 時間，整個查詢使用了 224382 毫秒的 CPU 時間。獲得更好性能的最直接方法是改進
RSTReclassedJournalEntries表上的索引。該表只有 127787 行，因此更好的索引所需的額外維護不太可能成為問題。使用鍵列創建索引Posted就ReclassedJRNENTRY足夠了。
The IX_RSTReclassedJournalEntries_1index 已經存在於表中並且是一個覆蓋索引，但是您需要一個可以過濾Posted並ReclassedJRNENTRY作為搜尋謂詞而不是過濾謂詞的索引。使用這樣的索引，SQL Server 將從索引中讀取最多 34646 行，而不是 4382443766 行。這將顯著提高性能。我建議的索引更改解決了問題的症狀而不是根本原因，但有時這足以滿足業務需求。根本原因似乎是與 的連接基數估計問題
[SOLMQ].[dbo].[AAG30000].[AK2AAG30000]。解決這個問題可能比更改建議的索引更困難，儘管您可能會很幸運並且更新該表上的統計資訊也可以解決問題。
我建議保持新的兼容性級別並使用
traceflag 9481-
- 如果只是一個查詢，請使用查詢提示
OPTION (QUERYTRACEON 9481)。- 如果您看到很多查詢被退回，請啟用 traceflag 作為伺服器範圍選項 - dbcc traceon (9481,-1) 或將其添加為啟動參數，以便在重新啟動後保持不變。
- 確保您有正確的索引和最新的統計資訊。