SET NOCOUNT ON 能解决结果不一致，是因为它抑制 SQL Server 默认发送的“X 行受影响”消息，避免这些非结果集消息被客户端误解析为额外结果集，从而防止数据错位、截断或解析失败。
存储过程执行后结果集被干扰，根本原因不是数据逻辑错，而是SQL Server默认返回的“X行受影响”消息混入了结果流。
为什么 SET NOCOUNT ON 能解决结果不一致
SQL Server 存储过程中每条 INSERT、UPDATE、DELETE 语句执行后，默认会向客户端发送一条影响行数的消息（如 (5 行受影响)）。这些消息不是结果集，但某些客户端驱动（尤其是旧版 ADO.NET、PHP mysqli、Python pyodbc 的默认配置）会把它们当作额外的结果集接收——导致你 SELECT 返回的真正数据被错位、截断或解析失败。
典型表现：程序里用 fetchall() 拿到空列表，或第一条记录是乱码；SSMS 看起来正常，但 Java 应用拿到的却是第二条结果集（即那条 (1 行受影响)）。
- 该行为与 SQL Server 版本无关，是协议层设计，所有版本默认开启
-
SET NOCOUNT ON不影响事务、性能或实际执行逻辑，只抑制消息发送 - 必须放在存储过程开头（在
BEGIN后立即写），否则前面语句仍会发消息
不加 SET NOCOUNT ON 的常见错误现象
你在 SSMS 中看到结果正常，但程序调用时出错，大概率是以下之一：
- Java 使用
CallableStatement执行带OUT参数的存储过程，却在getResultSet()前没跳过第一条“行计数结果集”，直接报SQLException: No data found - Python
pyodbc调用后cursor.fetchall()返回空，但cursor.nextset()能切换到真正的数据集 - .NET
SqlDataReader在读第一行前就抛Invalid attempt to read when no data is present - SSMS 的“结果”页显示正常，但“消息”页有大量
(1 行受影响)—— 这就是干扰源
正确写法与兼容性注意点
在存储过程定义中，SET NOCOUNT ON 必须出现在可执行语句之前，且建议显式配对关闭（虽非必须）：
CREATE PROCEDURE usp_GetUser
@id INT
AS
BEGIN
SET NOCOUNT ON; -- ← 关键：放这里
<pre class="brush:php;toolbar:false;">SELECT id, name FROM users WHERE id = @id;
UPDATE user_log SET last_access = GETDATE() WHERE user_id = @id;
SET NOCOUNT OFF; -- ← 可选，仅用于调试时临时开消息
END
注意：
- 不要写成
SET NOCOUNT = ON（语法错误，会编译失败） - 如果存储过程中嵌套调用其他存储过程，被调用者也需各自设
SET NOCOUNT ON，父过程的设置不继承 - SQL Server 2005+ 全支持；SQL Server 7.0/2000 也支持，无需担心兼容性
为什么不能只靠客户端处理
理论上，客户端可以循环调用 nextset() 或忽略非数据结果集。但问题在于：
- 不同语言/驱动实现不一：Java JDBC 要手动
getMoreResults()，PHP PDO 默认PDO::ATTR_EMULATE_PREPARES=true时可能吞掉消息，行为不可控 - ORM 框架（如 Entity Framework、Django ORM）通常不暴露底层结果集切换逻辑，一旦遇到额外结果集就直接报错或静默丢弃
- 加
SET NOCOUNT ON是成本最低、效果最确定的解法——一行代码，全局生效
真正容易被忽略的是：这个设置不改变任何业务逻辑，但它决定了结果能不能被客户端干净地拿到。很多“结果不一致”本质是“结果被多塞了一堆不该有的消息”。
