參數嗅探：為什麼這會成為一個問題？

今天，我遇到了一個儲存過程在從 ASP.NET 網頁執行時超時（耗時超過 30 秒）的問題，但在從 SSMS 執行時卻快速執行（耗時 5 秒）。

在懷疑參數嗅探是罪魁禍首之後，我屏蔽了輸入參數，查詢執行得更快。

我的問題是：為什麼會這樣？

這個系統已經投入生產超過 5 年，這是我們第一次在我們的儲存過程中看到這樣的東西。這是“數據庫磨損”嗎？

我們已經解決了這個問題，所以這沒什麼大不了的，但我只是好奇為什麼會這樣。

基本上發生的情況是，當 SQL Server 看到需要編譯的查詢時，它將使用首次呼叫的參數來生成執行計劃。這可能是也可能不是一件好事，但這就是發生的事情。

例如，假設您有一張水果表（100 行）。有 98 行是蘋果，只有 2 行是橙子。如果您在該表中查詢 Apple，那麼該計劃很可能會通過 Scan 進行編譯。這是一件好事，因為它針對 Apple 查詢進行了優化。但是，當您要查詢 Orange 時，該 Scan 效率低下。但正在使用的是儲存的計劃。

事實是它發生了。它一直在發生。這通常不是一個突出的問題，但在某些情況下它可能是一個相當大的問題。一個持續的錯誤參數嗅探問題的解決方案是，您可以利用OPTIMIZE FOR查詢提示強制 SQL Server 在初始編譯時生成執行計劃時使用某些參數值。

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