我從一個網站查詢了15到30秒，同時查詢從SQL Server Management studio運行了0.5秒。我無法使用SQL Profiler查看任何鎖定問題，也無法從SSMS手動重現延遲。一週前，我分離並重新連接了數據庫，似乎奇蹟般地解決了這個問題。今天，當問題重新擡頭時，我試圖重建索引。這也解決了這個問題。不過，據我所知，我認爲這不一定是索引問題，因爲索引不會自動重建爲簡單的分離/附加。SQL Server查詢在ADO.NET中運行速度比在SSMS中慢
任何想法可能會導致延遲？我的第一個想法是，也許一些參數嗅探存儲過程被調用（表示存儲過程運行CTE，如果重要的話）導致了一個錯誤的查詢計劃，這將解釋問題的間歇性。由於分離/重新連接和索引重建在理論上應該使緩存查詢計劃無效，這是有道理的，但我不確定如何驗證這一點。此外，爲什麼不通過SSMS手動運行相同的查詢（直接從具有完全相同參數的SQL事件探查器複製）顯示相同的延遲？
有什麼想法？
如果一個錯誤的計劃被緩存，那麼同樣的錯誤計劃也應該從SSMS中使用，如果你使用相同的參數運行完全相同的查詢。
找到根本原因不可能有更好的解決方案。試圖窺視和戳穿各種設置，希望它能夠修復這個問題永遠不會給你實際上修復的信心。此外，下次系統可能會遇到不同的問題，您會相信這個問題會重新出現並應用一個不好的解決方案。
最好的嘗試是捕獲不良執行計劃。 Showplan XML Event Class事件探查器事件是你的朋友，你可以得到ADO.Net調用的計劃。這是一個非常沉重的事件，所以你應該附加探查器，並在短時間內只有當問題出現時才捕獲它。
查詢IO統計信息也可以提供幫助。 RPC:Completed和SQL: Batch Completed事件都包含讀取和寫入，因此您可以比較ADO.Net調用與SSMS執行的邏輯IO的數量。較大的差異（對於完全相同的查詢和參數）表示不同的計劃。 sys.dm_exec_query_stats是另一個調查途徑。您可以在那裏找到您的查詢計劃並檢查執行統計。
所有這些應該有助於確定如果問題是一個糟糕的計劃或其他事情，首先。
「壞」查詢的讀取次數顯着高於SSMS查詢的讀取次數。我也認爲如果輸入完全相同的查詢，SSMS應該使用相同的查詢計劃，但是有沒有一種情況可能不是這種情況？ – Chris 2009-11-17 18:02:39
如果任何@parameter *類型*不同或者連接設置不同，則該計劃不能重用，SSMS將編譯自己的計劃。你的查詢中是否有任何@variables？ – 2009-11-17 18:32:54
我敢打賭，這是連接設置。當ASP.NET使用sql用戶時，我使用windows auth登錄到SSMS。這清除了這一點。現在，接下來要捕捉執行計劃中的錯誤.. :( – Chris 2009-11-17 18:39:38
在系統忙於做其他事情之後，您的ADO.NET查詢是否可能正在運行，以便它所需的數據不再位於RAM中？當你在SSMS上測試時，它是？
您可以通過運行SSMS以下兩個命令檢查您運行查詢之前：
CHECKPOINT
DBCC DROPCLEANBUFFERS
如果引起SSMS查詢運行緩慢，那麼有一些技巧，你可以在玩ADO.NET方面幫助它運行得更快。
我一直有同樣的問題。 我可以解決這個問題的唯一方法是設置ARITHABORT。 但不幸，當它再次發生我必須設置ARITHABORT關閉。
我不知道ARITHABORT與此有關，但它的工作原理，我一直有這個問題超過2年，現在仍然沒有解決方案。我對工作的databses超過300GB，所以也許這是一個規模的問題...
我得解決這個問題最近是從早期的崗位 Google Groups post
讓我知道如果你已成功地完全解決這個問題，因爲它非常令人沮喪！
我知道我對這個話題稱重很晚，但我想後的解決方案具有類似的問題時，我發現。簡而言之，在程序開始時添加SET ARITHABORT ON命令可以使網站查詢性能與SQL Server工具中的性能保持一致。當您從QA或SSMS運行查詢時，通常會在連接上設置此選項（您可以更改該選項，但這是默認選項）。在我的情況下，我有大約15個不同的存儲過程在相當大的一組數據（10到100幾千行）上進行數學聚合（SUM，COUNT，AVG，STDEV） - 添加了SET ARITHABORT ON選項將它們全部從3-5秒運行到20-30ms。
所以，我希望能夠幫助別人那裏。
+1因爲你的回答讓我解決了我的問題，我遇到了一個問題，從ADO調用spro時速度很慢，但是在SSMS中速度很快，更改sproc以包含SET ARITHABORT ON會加速（在另一方面，可能只是迫使它重新編譯和無效壞緩存執行計劃。） 我也發現這個一個有趣的討論：http://dba.stackexchange.com/questions/9840/why -would-設置ARITHABORT上，大大-加速-A-查詢 我認爲底線是SSMS中得到一個不同的執行計劃，因爲它的默認值設置的選項和ADO沒有。 – 2012-03-09 20:50:07
Simon Sabin在「如果查詢計劃出錯」（http://sqlbits.com/Sessions/Event5/When_a_query_plan_goes_wrong）中討論瞭如何通過使用各種「優化」提示來解決此問題，並幫助過程生成一致的計劃以及不使用默認參數嗅探。
但是，我有一個SSM計劃和ASP計劃完全相同的聚合索引/表掃描 - 而且ASP查詢需要3+分鐘而不是1秒。 （在這種情況下，表掃描恰好是在獲取結果如何回答。）
人照顧解釋那一個？
是SSMS傳遞一些提示或不同的連接字符串比ADO.net的方式嗎？ – shahkalpesh 2009-11-17 18:12:40
是的，我連接不同的憑據。不幸的是，目前這個問題已經消失，所以我不能用相同的連接設置進行測試，直到問題再次出現。 – Chris 2009-11-17 18:56:13
@Chris：你可以在你的案例中發表你自己的發現和答案嗎？ – shahkalpesh 2009-11-18 05:57:25