從網站調用時存儲過程執行時間大於30秒，但從ssms調用時小於1秒

我有一個由網站調用的用於顯示數據的存儲過程。今天，網頁已經開始超時，所以我得到了剖析器，並看到這個查詢耗時太長。然後，我使用相同的用戶登錄在管理工作室中運行相同的查詢，並且返回的時間不到一秒。從網站調用時存儲過程執行時間大於30秒，但從ssms調用時小於1秒

有沒有什麼明顯的可能導致這個？我想不出爲什麼當ASP調用存儲過程需要30秒，但是當我稱它爲好時。

感謝

來源

2010-05-11 Blootac

是否有很多併發進行？那麼參數呢？ – 2010-05-11 08:18:26

SMSS是連接到本地實例還是同一個遠程數據庫？只是想知道是否查詢返回的數據量會導致問題（例如，您不會在本地看到共享內存類型的連接）。 – Paolo 2010-05-11 08:21:32

代碼的樣子是什麼？ – Paddy 2010-05-11 08:34:46

它似乎是參數嗅探... 我已經停止了嗅探，將傳入的參數分配給局部變量，現在似乎很好（即它再次從網站下運行）。看看它是否保持這樣或者會再次降級會很有趣。

我曾假定運行選項RECOMPILE會暫時'固定'查詢有問題的參數嗅探問題，但它沒有。

好啊。謝謝大家回答。我會看到會發生什麼

來源

2010-05-11 08:52:04 Blootac

如果這最終成爲答案，請確認後再接受。我提到它，因爲你是新來的，歡迎！ – SqlRyan 2010-05-11 08:57:19

我猜想，可能有兩個原因：

網絡問題
參數嗅探

來源

2010-05-11 08:30:09 Cagdas

-1

聽起來像是一個死循環。

來源

2010-05-11 08:35:27

不，它不！這會導致其中一個參與事務被回滾，並且您會收到一條錯誤消息，告訴您發生了死鎖。 – 2010-05-11 09:05:39

這通常是因爲Management Studio連接和ASP連接（如SET ARITHABORT）之間的某些SET-tings不同。這並不能解釋爲什麼它只是從網站調用今天開始出現問題，但它有相當的機會。

來源

2010-05-11 08:40:24 Rob

還有一些很好的答案在http://stackoverflow.com/questions/2736638/sql-query-slow-in-net-application-but-instantaneous-in-sql-server-management-stu/可能是相關的 – Rob 2010-05-11 08:42:09

我不確定這是設置本身，可以解釋速度差異？更通常的情況是，如果你改變這些設置之一，你將得到一個新的或不同的執行計劃，所以它看起來像改變設置固定它，但實際上罪魁禍首是參數嗅探。 – 2010-05-11 09:08:59

我也是用ARITHABORT來體驗的。問題是查詢計算列上的索引，當設置ARITHABORT時性能更好。 – devio 2010-05-11 20:20:51

我們的IVR有類似的問題 - 當我通過SSMS運行查詢時，它立即返回，但是當它通過我們的IVR訪問的web服務運行時，它會超過大約20時間百分比 - 真的很奇怪。

我結束了在運行SQL事件探查器查看所提交的查詢，然後每個索引優化嚮導，其中第二每次下加快了IVR查詢到的建議，增加了一些額外的指標。我懷疑這個問題也與參數有關，雖然我沒有比較兩個不同場地的執行計劃，但我懷疑它們是完全不同的。不過，SQL Profiler將幫助您對此進行分類，因爲您可以看到實際提交給引擎的查詢以及用於提取數據的執行計劃。

來源

2010-05-11 09:00:50 SqlRyan

從網站調用時存儲過程執行時間大於30秒，但從ssms調用時小於1秒

回答

相關問題