SQL Server的性能 - 運行即席查詢與在存儲過程中編譯

Question

存在一個存儲過程運行速度非常慢（> 60秒）的邏輯原因，但是如果我運行與常規SQL腳本完全相同的代碼它會在不到3秒內執行？

以我的想法，他們應該運行相同的，但這不是我所看到的。我懷疑還有其他事情在發生，但是想看看是否有其他人看過類似的東西。

這種情況是我的客戶報告了一個運行緩慢的SP，我確認了，所以我添加了一個索引，運行了SP之外的代碼，運行得非常快，但之後我重新運行了SP，結果沒有提高。

爲了以防萬一，我也刪除並重新創建了SP，但不知何故，似乎它每次SP運行時都可能使用舊的執行計劃？

Answer 1

可能是參數嗅探或PROC也許是與設置ARITHABORT叫OFF

可以顯示的代碼？

Answer 2

爲存儲過程高速緩存單個執行計劃。如果基於參數，過程通常產生截然不同的結果/搜索模式，則可能使用次優緩存執行計劃來解析過程查詢。

一些方法來解決：

WITH RECOMPILE使用，這樣一個新的計劃，每次

使用提示來告訴優化如何做人（指數=，穩健plan..etc）

使用

重新設計程序/系統以確保與參數值無關的相似訪問模式。

Answer 3

這可能是一個緩存的執行計劃問題..我已經看到它發生了很多次存儲過程超時，但從查詢分析器運行相同的SQL將立即回來。這兩個簡單的方法，我知道此刻進行修復：

清除緩存執行

這將清除來自服務器的緩存壞計劃（連同一切）。不完全是一個長期的解決方案，因爲存儲過程將來可能會再次出現問題，但這是一個很好的臨時解決方案。

DBCC FREEPROCCACHE 
DBCC DROPCLEANBUFFERS 

添加WITH RECOMPILE存儲過程

CREATE PROCEDURE MyExample 
WITH RECOMPILE 
AS ... 

添加WITH RECOMPILE參數存儲過程使得SQL Server中創建一個新的執行計劃中的每個程序運行時間。這樣會傷害到性能，但如果整個程序運行速度比以前慢數千倍或超時，那麼採用小的性能命中率肯定會更好。

參數嗅探

看看這個article的參數在存儲過程中嗅探。根據文章，您可以稍微修改您的存儲過程代碼以禁用MS SQL的參數嗅探，這也有助於解決問題。