強制參數化生成重複計劃

https://www.brentozar.com/pastetheplan/?id=H1qoS7BSu

我正在使用帶有強制參數化和 MAXDOP 8 的 Azure SQL 18 vCore db。對於其他 db 但對於相同的查詢，vCore 計數可能會更改得更低。執行 sp_blitzcache 已顯示帶有以下警告的查詢：

Compilation Timeout, Forced Parameterization, Multiple Plans (11), Plan created last 4hrs, Long Running With Low CPU, Many Rows Table Spool, non-SARGables

主表大約有 600Krows，兩個輔助表大約有 200 行。

我是一個新手，對其中的一些事情感到好奇。目前記憶體中有大約 2700 個計劃用於此 query_hash，所有計劃都使用相同的 query_plan_hash。編譯在很大一部分時間中都會超時（無法確認每次都是如此）。我即將打開 traceflag 4199 以希望擺脫超時，並且查詢的性能在我所知道的應用程序上下文中是可以接受的，但我想了解是什麼阻礙了編譯器。感謝您對此的任何幫助！

您將無法在 Azure SQL Server 中打開跟踪標誌 4199。您將收到一條錯誤消息。事實上，您不能在 Azure SQL 數據庫中打開任何跟踪標誌（全域或會話範圍）。在撰寫本文時，為 Azure SQL 數據庫啟用了 24 個跟踪標誌。您可以通過執行來檢查列表DBCC TRACESTATUS。如果您想模仿 TF4199 的相同行為，請執行以下 T-SQL 語句。

ALTER DATABASE SCOPED CONFIGURATION SET QUERY_OPTIMIZER_HOTFIXES = ON ;

參考：ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)

我建議你閱讀這篇文章：

了解優化器超時以及復雜查詢如何在 SQL Server 中受到影響 Joseph Pilov

再加上看看你從跑步中得到的其他提示，sp_blitzcache並嘗試解決這些問題。

• 多行表線軸

  • Hugo Kornelis 的桌軸
  • Paul White 的嵌套循環連接和性能線軸

• 非SARGables

  • Brent Ozar 的非 SARGable 謂詞
  • Brent Ozar修復非 Sargable 查詢的兩種方法

引用自：https://dba.stackexchange.com/questions/289190