SET NOCOUNT ON真的使性能差異如此之大

Question

在這article中，作者建議有與SET NOCOUNT ON相關的材料開銷，並且「通過從網絡中移除此額外開銷，它可以極大地提高數據庫的整體性能和應用程序「

作者引用了默認存儲過程模板從2000年到2005年的更改，並建議」Microsoft甚至意識到這個問題「，它促使此模板發生更改。

是否有人有確鑿的證據支持或反駁聲稱的性能增益與設置NOCOUNT ON。

Answer 1

我的問題的最後一個鏈接在這裏：「SET NOCOUNT ON usage」是指article on it。

鑑於它是多麼微不足道，爲什麼不讓它進入並停止客戶端處理另一個結果集呢？

而且沒有SET NOCOUNT ON，NHibernate的可以打破過（在問題中提到）

Answer 2

有場景中SET NOCOUNT ON是強制性的。在設計基於通過SqlClient的BeginExecuteXXX方法利用線程池的異步處理的高性能中間層時，行計數存在非常嚴重的問題。只要服務器返回第一個響應數據包，BeginExecute方法就會完成。但是，當調用EndExecuteXXX時，這將在調用完成時在非查詢請求上完成。每個rowcount響應是一個響應。在處理複雜的程序時，第一行數可以在5-10毫秒內返回，而通話在300-500毫秒內完成。在500ms之後回調submited異步請求，而不是在5ms後回調，然後回調在EndExecuteXXX中阻塞495ms。結果是異步調用提前完成，並在EndExecuteNonQuery調用中阻塞線程池中的線程。這導致ThreadPool飢餓。我已經看到，通過在特定場景中添加SET NOCOUNT ON，高性能系統可將吞吐量從每秒數百個呼叫改善爲每秒數千個呼叫。

鑑於對於高規模/高吞吐量midle層處理異步調用是唯一的方法，NOCOUNT幾乎是一個強制性要求。

Answer 3

我同意使用NOCOUNT是一個好主意。 將其添加到在每個SPROC或動態SQL語句中執行的所有代碼是一個糟糕的主意。

特別是如果你正在談論高性能。應根據數據訪問層中的代碼的需要設置TSQL NOCOUNT。就像交易和鎖定水平一樣。

每次在每次執行的SQL中設置這些東西都不會讓您獲得通過在連接應用程序的代碼中設置好的性能提升。

通過編寫更好的代碼，而不是將SET NOCOUNT語句添加到所有SQL，可以找到更好的性能。