關於 sp_recompile 的一般問題
對於幾個場景，不是很多次，但我們很少看到在儲存過程上執行 sp_recompile 可以提高性能。
作為一名 DBA，我了解在進行 sp_recompile 時所涉及的一些警告以及為什麼它會提高性能。
我們的管理層一直在爭論是否向 Application/DEV DBA 提供在看到上述性能問題時進行 sp 重新編譯的訪問權限。只是為了減少 DBA 的參與，並且 APP 開發人員可以在性能問題期間在其上執行
我很猶豫，因為我認為它會帶來一些不需要的行為，有時甚至會惡化其他 proc 的性能。
我正在向您的專家尋求一般指導和經驗，為什麼在可能的不同情況下或在理想情況下這可能是一個壞主意。您的輸入可能會幫助我進行設計，並且可能會以不同的方式解釋該方法。
僅供參考-當看到參數嗅探等問題時，不僅在一個應用程序中，而且在少數其他應用程序中都認為上述是自動化的。
失去的一件事
sp_recompile是它適用於儲存過程之外的對象。從文件：目前數據庫中儲存過程、觸發器、表、視圖或使用者定義函式的限定或非限定名稱
如果有人在腦海中產生一個奇怪的想法，他們最終可能會影響不止一個程序：
如果 object 是表或視圖的名稱，則所有引用表或視圖的儲存過程、觸發器或使用者定義的函式將在下次執行時重新編譯。
如果開發人員已經有能力使用其他風格的重新編譯提示，最好讓他們在適當的時候使用這些提示，但也要讓他們了解重新編譯的範圍的差異，以及他們如何處理參數：
對於至少執行 SQL Server 2008 build 2746（帶有累積更新 5 的 Service Pack 1）的實例，使用 OPTION (RECOMPILE) 與 WITH RECOMPILE 相比具有另一個顯著優勢：只有 OPTION (RECOMPILE) 才能啟用參數嵌入優化。
一般來說，
WITH RECOMPILE應該避免——這是一種非常嚴厲的方法。我贊成針對重新編譯提示來臨時解決問題，或者當問題的其他潛在解決方案沒有吸引力時。