查詢超時 - 零星

Question

讓ASP.net Web應用程序查詢來自SQL Server 2005數據庫的數據。有一個頁面會偶爾超時。

追溯代碼並找到SQL。通過查詢工具運行SQL，它總是在2秒內運行。 SQL Server的默認超時時間是10分鐘。

此問題的解決方法是將sql server超時更改爲20分鐘，然後再更改爲10分鐘。然後頁面通常需要2秒鐘來查詢和顯示。

看過可能的鎖定，但沒有顯示會導致問題。關於唯一的結論是重置超時設置正在殺死一個進程。

尋找一些可以追蹤的想法。

謝謝

Answer 1

有兩種不同的超時在這裏玩。連接超時（在連接字符串中指定，並作爲SqlConnection的屬性）和查詢超時（屬性SqlCommand.CommandTimeout）。默認值爲：

• 連接超時：15秒。
• 查詢超時：30秒。

查詢超時被定義爲「所有網絡的累積超時的結果的命令執行或處理過程中進行讀取。在返回的第一行後仍可以發生超時，並且不包括用戶處理時間，只有網絡讀取時間「

網絡讀取時間消耗（包括網絡爭用）的很多原因。我會尋找的東西：

• 阻塞在SQL Server中。
• 統計數據過期。
• 執行計劃。你在查詢分析器中獲得了很好的執行計劃嗎？
• 陳舊/欠佳的執行計劃緩存。如果問題查詢是參數化存儲過程或查詢，則緩存的執行計劃是在首次執行查詢時獲取的。它基於第一次調用的參數值。如果爲該調用提供的參數是異常值/非正常值，則對於大多數執行，緩存的執行計劃可能不是最理想的。
• 存儲過程重新編譯。一個交織SQL/DML和DDL的存儲過程（例如，將SELECT語句與創建臨時表交錯）將導致每次創建臨時表時都會重新編譯。編譯鎖可以防止相同存儲過程的其他執行者繼續執行，直到執行計劃重新編譯完成。如果您使用臨時表，應在執行任何DML CRUD之前先聲明它們。

如果您通過連接字符串指定了連接超時，則不會使用現有的連接SQL Server連接：由於連接池高速緩存基於所使用的連接字符串，因此會獲得全新連接。你正確地Dispose（）'你的連接/命令/等？如果你留下一個閱讀數據的開放閱讀器，你可能會留下一個鎖，導致問題。有時，SQL Server扼流器會丟棄連接並留下一個鬼spid，這也會引起類似的鎖爭用問題。