儲存過程突然變慢的執行計劃
我試圖了解我們在使用 SQL Server 2000 時遇到的問題。我們是一個中等事務網站，我們有一個名為的儲存
sp_GetCurrentTransactions過程，它接受一個客戶 ID 和兩個日期。現在，根據日期和客戶，此查詢可以返回從零到 1000 行的任何內容。
問題：我們所經歷的是，
Execution Timeout Expired當他們嘗試執行該儲存過程時，我們會突然為特定客戶端收到許多錯誤（通常或類似）。所以我們檢查查詢，在 SSMS 中執行它，發現它需要 30 秒。所以我們重新編譯儲存的 proc 並 -bang- 它現在在 300 毫秒內執行。我已經和我們的 DBA 談過這個問題。他告訴我，當我們創建儲存過程時，數據庫創建了一個查詢計劃。他說對於那組參數來說這是一個很好的計劃，但是如果你給它扔一組參數，那麼這個計劃就不是那個數據的最佳計劃，所以你會看到它執行得很慢。
呈現給我的選項是將問題查詢從儲存的過程轉移到動態 SQL 中，動態 SQL 在每次執行時都會創建執行計劃。
這對我來說就像是退後一步，我覺得必須有辦法解決這個問題。有沒有其他方法來處理這個問題？
任何和所有的回應都表示讚賞。
這個問題稱為參數嗅探。
更高版本的 SQL Server 為您提供了更多處理它的選項，例如
OPTION (RECOMPILE)或OPTIMIZE FOR提示。您可以嘗試在儲存過程中聲明變數，將參數值分配給變數並使用變數代替參數，因為這聽起來好像大多數時候您都得到了一個相當令人滿意的計劃。
通常，最糟糕的計劃是那些為具有非常高選擇性的參數編譯但執行具有低選擇性的參數的計劃。
假設使用這種方法生成的計劃更健壯並且對所有參數值都滿意，那麼這種方法相對於 JNK 建議的方法的優勢在於它不會為每次呼叫產生編譯成本。
缺點是，對於某些執行，執行時間可能比專門為這些參數值定制的計劃要長，因此這是編譯時間與執行時間的權衡。