Sometimes even the simplest things can make a difference. One of these simple items that should be part of every stored procedure is SET NOCOUNT ON. This one line of code, put at the top of a stored procedure turns off the messages that SQL Server sends back to the client after each T-SQL statement is executed. This is performed for all SELECT, INSERT, UPDATE, and DELETE statements. Having this information is handy when you run a T-SQL statement in a query window, but when stored procedures are run there is no need for this information to be passed back to the client.

通过从网络中移除这种额外的开销，可以极大地提高数据库和应用程序的整体性能。

如果您仍然需要获得受正在执行的T-SQL语句影响的行数，您仍然可以使用@@ROWCOUNT选项。通过发出SET NOCOUNT ON，这个函数(@@ROWCOUNT)仍然可以工作，并且仍然可以在存储过程中使用，以确定有多少行受到语句的影响。

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

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

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

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

为了找到关于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.

设置nocount on; 以上代码将在DML/DDL命令执行后，停止sql server引擎生成的消息到前端结果窗口。

我们为什么要这么做? 由于SQL server引擎获取状态并生成消息需要消耗一定的资源，因此对SQL server引擎来说是一种过载。所以我们设置了noncount消息。

冒着让事情变得更复杂的风险，我推荐一个与我上面看到的略有不同的规则:

总是在proc的顶部设置NOCOUNT ON，在你在proc中做任何工作之前，但也总是在从存储的proc返回任何记录集之前再次设置NOCOUNT OFF。

所以“通常不要指望，除非你实际返回一个结果集”。我不知道这可以破坏任何客户端代码的任何方式，这意味着客户端代码永远不需要知道任何关于过程内部的信息，而且它不是特别繁重。