OPTION (RECOMPILE) 是否在生產環境中使用？

OPTION (RECOMPILE)用於生產？

這個選項似乎得到了很多壞消息。這是應得的嗎？

我有一個 DBA，到目前為止，他不喜歡OPTION (RECOMPILE)Report ETL ssis 代理查詢這一想法。這些查詢（據我所知）按計劃的時間間隔按順序執行。

返回曆史：

• SQL 伺服器 2016
• 通過 ssis 代理執行時導致聚集索引掃描的 ETL 查詢。這些查詢需要幾分鐘才能完成並造成嚴重影響。
• 通過本地儲存過程執行的相同查詢和參數在不到一秒的時間內執行。

等等，你確定 OPTION (RECOMPILE) 是答案嗎？

• 未知。
• 但在我嘗試之前，我需要知道這是否是一個非常糟糕的主意。

我知道的風險：

• 過去至少有兩個與 OPTION (RECOMPILE) 相關的嚴重錯誤。同時執行的兩個查詢可以交換結果集。啊！！ https://support.microsoft.com/en-us/topic/fix-rare-possibility-of-incorrect-results-when-you-use-option-recompile-for-queries-inside-a-procedure-in- sql-server-2014-或-sql-server-2012-c247fbb5-4125-dd0f-7789-7b1c126f8241

因此，鑑於上述情況 - 這個選項實際上是否在現實世界中使用？我推薦（並測試）它作為生產環境的一個選項是否可以接受？

---

我被要求提供更多細節。我提到我確實有其他與該主題相關的文章。讓我提供更多資訊：

• 根本問題是來自應用伺服器的查詢花費的時間超過 60 秒。通常這些查詢需要 4 到 10 秒。經過很多痛苦，我確定超時與 ETL 查詢一致。15 個查詢中有 4 個是具體的。
• 在應用程序伺服器中發現了導致問題的因素。具體而言，隔離級別設置為serializable休眠層內；我了解到，這對於大批量生產環境來說並不是最佳選擇。

讓我分享其他問題：

SQL Server - 我可以手術刪除一個糟糕的記憶體查詢計劃還是我追求錯誤的想法？

為什麼通過 SSIS 在 ETL 中的查詢很慢，但通過本地儲存過程卻很快？

OPTION(RECOMPILE)用於真實的文字製作場景。我用它來解決參數嗅探和優化廚房水槽查詢。這可能是您問題的答案，但症狀表明OPTIMIZE FOR UNKNOWN（與局部變數相同）也可能解決問題。

我當然不會因為曾經存在過一個錯誤而迴避一個選項，並且它在幾年前就已修復。主要風險OPTION(RECOMPILE)是使用不當，例如高頻查詢。

是的。OPTION RECOMPILE 適用於查詢成本因參數值而顯著變化的高成本/低頻查詢。作為替代方案，請考慮使用Query Store，您可以在其中強制制定一個好的計劃。

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