我有一個存儲過程，每天運行九次，午夜過後。這不是一個理想的存儲過程，但你知道它是如何。沒有計劃能夠與現實保持聯繫。sql server存儲過程中的首次運行緩慢
該存儲過程通常需要大約一分鐘的時間運行，給予或花費其處理的數據量的時間。但是，對於某個早晨的第一次運行，有時會花費過多的時間，有時甚至比通常花費的時間長得多（如果它完成的話）。如果我殺了它並重新啓動它，它會正常運行。
我正在尋找一個優雅的解決方案 - 至少比我的第一個想法更優雅，那就是先打一個額外的跑步，先不要生成我使用的數據，並且可以容忍其中的失敗。
有沒有人見過這種行爲？你是如何解決它的？
它可能是編譯時和冷數據緩存（緩衝池）。如果通常需要一分鐘，那麼我認爲它也很笨重。
編譯時間：執行計劃在統計更新時失效。如果您有批量處理或過夜維護，您可能會遇到這種情況：您需要將數據/索引頁面從磁盤傳輸到內存中。
爲了減輕這些：
我們有同樣的問題，有時，特別是在發展框，以我們的網站超時爲例。我們只需再次點擊...
存儲過程分散在sqlserver中。
如果使用DBCC FREEPROCCACHE它會重新編譯sql語句。
如果您的服務器正在重新啓動（例如每晚或每週），可能會清除緩存，這會導致查詢在第一次嘗試時運行緩慢。
你可以通過運行上述命令並運行查詢來查看是否發生了同樣的事情......如果是的話我會說你的緩存已經被清除了。
爲了提供解決方案，首先要做的是調查原因。可能會出現許多問題，這些問題會顯示爲您描述的症狀。 總是通過遵循調查方法開始排除性能問題，如Waits And Queues。這將揭示爲什麼是第一次運行緩慢的過程。罪魁：
取決於你發現了什麼作爲的問題，將是一個合適的解決方案。
你應該做的一件事不是做的是盲目地改變設置，希望問題消失，不要理解錯誤。
對於數據庫，AUTO_UPDATE_STATISTICS或AUTO_UPDATE_STATISTICS_ASYNC是？可能是第一次運行注意到統計數據需要更新並且這樣做。在前一個選項中，它等待狀態更新完成，對於後者，它不會等待狀態更新，但可能選擇次優計劃，從而導致性能不佳。
在proc每天第一次運行的同時還會發生什麼？它可能是從其他進程（備份，統計信息更新，其他預定作業）獲取鎖嗎？
您是否使用任何動態SQL或非sargable參數？ – Matthew 2011-02-14 18:33:50
並且是否有任何理由緩存存儲過程執行計劃一夜之間會丟失？ – Rup 2011-02-14 18:34:39
@Rup：統計數據更新爲 – gbn 2011-02-14 18:39:33