存儲過程的性能inconsistancy

運行SQL Server存儲過程時，我們遇到了一個奇怪的場景。當使用相同的參數運行完全相同的過程時（我們通過SQL Server Profiler捕獲了這個過程），我們得到非常可變的CPU使用率。現在顯然這取決於服務器負載和服務器上正在進行的其他活動。然而，我不希望我們在後續場合運行SP時遇到的「讀取」變化 - 相隔僅幾分鐘。存儲過程的性能inconsistancy

Day Hour Min CPU  Reads 
70 15 54 4851 33079 
70 15 54 5960 33723 
70 15 58 5538 30189 
70 16 10 5226 29672 
70 16 12 24102 1019178 
70 16 17 23915 1017621 
70 16 17 26348 1018690 
70 16 30 6443 28121 
70 16 30 6474 28539 
70 16 33 5242 27245 
70 16 33 6365 27338 
70 16 35 5413 27335

Bizzare。爲什麼當我們以前沒有那麼重設自己時，我們會突然得到一大堆讀數。我再說一次 - 我們對這個過程有完全相同的參數，所以爲什麼它突然決定它需要做一些讀操作有點奇怪。

上看看有什麼想法？我們知道一些額外的查詢可能會帶來一些好處（例如，查詢分析器提供了一個查詢分析器），但我們不希望看到大致相同的讀取次數？

感謝安迪

來源

2014-03-13 Andy Macnaughton-Jones

請問您能否添加過程定義？ –

檢查在讀取時間上升到stp所使用的表之前是否存在任何插入。 – Archlight

聽起來像可能的參數嗅探問題。 – 2014-03-13 12:13:39

你在生產環境中運行這個地方的其他人也跑了嗎？然後，它可能是一個參數嗅探問題，因爲編譯時執行計劃是爲了獲得最佳性能而編譯時提供的參數。

你可以嘗試添加With Recompile，看看問題是否會消失！

來源

2014-03-13 12:05:33 Peter

擊敗我:)其他選項將代替RECOMPILE（因爲它昂貴）爲每個參數聲明局部變量，爲它們分配參數並在SP代碼中使用它們而不是參數。 – Dimitri

好主意，但在某些情況下，重新編譯實際上可能會更便宜，然後運行查詢的非優化版本，所以請試試！ – Peter

存儲過程的性能inconsistancy

回答

相關問題