SET NOCOUNT ON是否真的会产生很大的性能差异

Question

在此article中，作者建议存在与SET NOCOUNT ON相关的物质开销，并且“通过从网络中删除这些额外开销，它可以极大地提高数据库和应用程序的整体性能”< / p>

作者引用了默认存储过程模板从2000到2005的更改，并建议“Microsoft甚至意识到这个问题”，这促使此模板发生了更改。

是否有人有确凿的证据表明，如果将NOCOUNT设置为ON，则支持或驳斥所声称的性能增益。

Answer 1

有些情况下SET NOCOUNT ON是强制性的。当基于通过SqlClient的BeginExecuteXXX方法利用线程池的异步处理设计高性能中间层时，行计数存在非常严重的问题。一旦服务器返回第一个响应数据包，BeginExecute方法就会完成。但是，当调用EndExecuteXXX时，当调用完成时，这将在非查询请求上完成。每个行数响应都是响应。当处理甚至模式复杂的程序时，第一行计数可以在5-10毫秒内返回，而呼叫在300-500毫秒内完成。它不会在500ms后回调提交的异步请求，而是在5 ms后回调，然后在EndExecuteXXX中回调阻塞495 ms。结果是异步调用过早完成并在EndExecuteNonQuery调用中阻塞线程池中的线程。这导致ThreadPool饥饿。我已经看到高性能系统只需在特定情况下添加SET NOCOUNT ON，就可以将吞吐量从每秒数百个呼叫提高到每秒数千个呼叫。

鉴于对于高规模/高吞吐量的中间层处理，异步调用是唯一的方法，NOCOUNT几乎是强制性要求。

Answer 2

我的问题中的最后一个链接：“SET NOCOUNT ON usage”指的是article on it。

考虑到它是多么微不足道，为什么不将它留在并停止客户端处理另一个结果集？

没有SET NOCOUNT ON，nHibernate也会破坏（提到的问题）

Answer 3

我同意使用NOCOUNT是一个好主意。 将它添加到每个SPROC或动态SQL语句中执行的所有代码是一个糟糕的主意。

特别是如果你在谈论高性能。应根据数据访问层中的代码设置TSQL NOCOUNT。就像交易和锁定级别一样。

每次在执行的SQL中设置这些内容时，每次执行时都不会通过在连接应用程序的代码中设置它们来提高性能。

通过编写更好的代码而不是通过向所有SQL添加SET NOCOUNT语句来找到更好的性能。