合理的SQL超時

當您對數據庫執行查詢時，什麼是合理的超時策略。通常我會保留默認值，但是想知道是否有明智的經驗法則？ DBA通常喜歡看什麼？合理的SQL超時

2011-11-06 sgtz

這是其中之一「它取決於」的答案。數百萬行數據的默認設置超時會導致很多昂貴的查詢。

我用的一個策略是：被設置爲0（換句話說，無超時），然後使用SQL事件探查器（運行跟蹤），以獲得時間。我多次用1.15給自己一個15％的緩衝區，這樣我就不會因爲系統延遲或者只是一個「慢」執行而超時。但在我看來，如果測試過了115％的時間已經過去並且沒有完成，那麼10次中有9次出錯，並且超時是有序的。

來源

2011-11-06 20:01:02

很酷。那麼你設定了一個相當嚴格的限制。這是我在想的方向。保持持續時間是否需要很多努力？也許如果達到持續時間閾值，則這是需要性能調整的指標。你對此有何看法？ – sgtz

它並不需要太多的努力。如果你喜歡（或更多）如果你的服務器有零星的表現，你可以放鬆現在的緩衝區高達25％。我同意，如果超時頻繁發生，只要沒有錯誤持續存在，這是一個非常直截了當的跡象，表明性能已經下降，需要注意/調整。 – 2011-11-06 21:39:44

如果您正在使用的SqlCommand和SqlConnection的類連接到SQL Server，然後有兩個超時，你需要考慮：

SqlConnection.ConnectionTimeout

才能到數據庫的連接所需的時間，默認爲30秒，這在我看來太長了。我們減少到5秒。

而且

SqlCommand.CommandTimeout

這顯然取決於你正在運行的查詢。

來源

2011-11-06 17:53:20

我認爲這真的取決於你在做什麼。如果我們正在談論報告，那麼您可能需要比如果您正在進行簡單的選擇/插入/刪除更高的超時。

我們通常只允許30秒的非報告查詢和3米的報告服務器。

來源

2011-11-06 17:53:57 UnhandledExcepSean

你會拋出這些值在配置文件或硬編碼他們？ – sgtz

硬編碼不好。幾乎永遠。 – UnhandledExcepSean

合理的SQL超時

回答

相關問題