SET NOCOUNT ON 真的能带来那么大的性能差异吗

In this article，作者认为存在与以下相关的材料开销SET NOCOUNT ON并且“通过消除网络的额外开销，可以极大地提高数据库和应用程序的整体性能”

作者引用了从 2000 年到 2005 年默认存储过程模板的更改，并表示“微软甚至意识到了这个问题”，从而促使了该模板的更改。

是否有人有确凿的证据支持或反驳通过设置 NOCOUNT ON 所声称的性能增益。

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

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