在動態 SQL 中使用 OPTION(RECOMPILE) 有意義嗎？
我想知道在執行動態 sql 查詢時使用OPTION(RECOMPILE)是否有益？
有幾點要記住：
- 將創建數百個（甚至數千個）不同的動態查詢。
- 其中大約 1/4 會以“更高頻率”重複使用。假設每天數百次（即每天執行 1 個特定查詢的數百次）。
- 其餘的將偶爾使用，可能是每天幾次，可能是一周幾次。
- 即使查詢應該以與之前的查詢基本相同的方式（即加入相同的表等）來“組合”。還有一個輸入變數的問題。
- 至少 2 個對象（表、視圖、連接等）將在每個查詢中發揮作用。最多會有幾十個對象，平均應該在 10 個左右（這應該與 1/4“高頻”查詢鬆散相關）
- 目的是優化速度。
預先感謝您的任何提示和建議。
使用的數據庫：MS SQL 2019
不。
既然我已經解決了這個問題，🙂，在需要使用它們之前不需要使用查詢提示。換句話說，不要主動使用它們，只有在您確定查詢的案例將從它們中受益之後才被動地使用它們。
現在到細節。
OPTION (RECOMPILE)（和RECOMPILE提示）在沒有替代解決方案的邊緣情況參數嗅探問題中很有用，正如Kendra Little 文章中所討論的那樣。在您確定您的Dynamic SQL存在其他無法解決的****參數嗅探問題之前，無需使用查詢提示。實際上，它只會減慢您的查詢速度，可能會減少很短的時間，但當您以高頻率一遍又一遍地重新編譯相同的查詢時，可能不會。OPTION (RECOMPILE)SQL Server 記憶體查詢計劃的原因是為了減少重複執行相同查詢的延遲，如果可能的話，不必重新編譯和重新決定使用什麼執行計劃來為您的查詢提供服務。此外，每次從上次執行或不再在計劃記憶體中對其進行任何更改時，您的動態 SQL都會引發重新編譯，因為記憶體的查詢計劃只能由相同的確切查詢重用（即使是註釋更改將生成一個新計劃），因為查詢文本作為記憶體計劃的鍵被散列。
說了這麼多，我只想重申，查詢提示不一定是壞事，不要讓我上面的“硬不”把你嚇跑。只是查詢提示旨在用於更多邊緣情況，而不是您的正常案例，並且使用不當實際上會嚴重影響性能。
OPTION (RECOMPILE)是一個很好的工具，當您在參數嗅探性能堵塞作為臨時快速修復時，或者當有一個實際有效的案例可以使用它時，它是一個很好的工具。但我絕對不建議在沒有測試的情況下使用它來備份它，動態 SQL並沒有什麼特別之處，它自動使用RECOMPILE提示是有意義的。