为了找到关于NOCOUNT的真实基准数据，我花了很多时间进行挖掘，所以我想分享一个简短的总结。

If your stored procedure uses a cursor to perform a lot of very quick operations with no returned results, having NOCOUNT OFF can take roughly 10 times as long as having it ON. 1 This is the worst-case scenario. If your stored procedure only performs a single quick operation with no returned results, setting NOCOUNT ON might yield around a 3% performance boost. 2 This would be consistent with a typical insert or update procedure. (See the comments on this answer for some discussion about why this may not always be faster.) If your stored procedure returns results (i.e. you SELECT something), the performance difference will diminish proportionately with the size of the result set.

好了，现在我做了我的研究，事情是这样的:

在TDS协议中，SET NOCOUNT ON每次查询只节省9个字节，而文本“SET NOCOUNT ON”本身是一个巨大的14个字节。我曾经认为受影响的123行是在一个单独的网络数据包中以纯文本从服务器返回的，但事实并非如此。实际上，它是嵌入在响应中的一个名为DONE_IN_PROC的小结构。它不是一个单独的网络数据包，因此不会浪费往返。

我认为您几乎总是可以坚持默认的计数行为，而不用担心性能。但是在某些情况下，预先计算行数会影响性能，例如只向前游标。在这种情况下，NOCOUNT可能是必需的。除此之外，绝对没有必要遵循“尽可能使用NOCOUNT”的座右铭。

这里有一个关于SET NOCOUNT设置不重要的非常详细的分析:http://daleburnett.com/2014/01/everything-ever-wanted-know-set-nocount/

如果你说你可能有不同的客户端，经典的ADO有问题，如果SET NOCOUNT没有设置为ON。

我经常遇到的一个问题是:如果一个存储过程执行了许多语句(因此返回了许多“受影响的xxx行”消息)，ADO似乎没有处理这个问题，并抛出错误“无法更改以Command对象作为源的记录集对象的ActiveConnection属性”。

所以我一般建议打开它，除非有非常非常好的理由不打开。你可能已经找到了非常非常好的理由，我需要进一步阅读。

关于破坏NHibernate的触发器，我有第一手的经验。基本上，当NH执行UPDATE时，它预计受影响的行数是一定的。通过将SET NOCOUNT ON添加到触发器，您可以获得NH期望的行数，从而解决问题。所以，如果你使用NH，我绝对建议关闭触发器。

至于在SPs中的使用，这是个人喜好的问题。我总是关闭行计数，但话说回来，这两种方法都没有真正有力的论据。

另一方面，您应该真正考虑远离基于sp的体系结构，这样您甚至不会遇到这个问题。

SET NOCOUNT ON-将显示“Command(s) completed successfully”。 SET NOCOUNT OFF-它将显示”(No。受影响的行)”。

我想在某种程度上这是一个DBA vs.开发人员的问题。

作为一个开发人员，我会说除非你绝对有必要，否则不要使用它——因为使用它会破坏你的ADO。NET代码(如Microsoft文档所示)。

我想作为一名DBA，您应该站在另一边——只要有可能就使用它，除非您真的必须阻止它的使用。

同样，如果你的开发者使用了ADO返回的“RecordsAffected”。NET的ExecuteNonQuery方法调用，如果每个人都使用SET NOCOUNT ON，您就会遇到麻烦，因为在这种情况下，ExecuteNonQuery总是返回0。

也可以看看Peter Bromberg的博客文章，看看他的立场。

所以归根结底是谁来制定标准:-)

Marc