SQL Server存储过程需加SET NOCOUNT ON并显式调用NextResult()等方法才能获取多个SELECT结果集，否则客户端仅接收第一个结果或被“X行受影响”消息干扰；MySQL/PostgreSQL不原生支持该机制。
为什么存储过程里写了 SELECT 却收不到结果集？
根本不是 SQL 写错了，而是客户端或调用方式不匹配。SQL Server 和 MySQL 都允许存储过程中直接 SELECT，但结果能否被上层程序拿到，取决于是否触发了「多结果集」通道，以及是否被中间层静默吞掉。
- SQL Server 默认在每个语句后返回「受影响行数」（比如
INSERT返回 1），JDBC 或某些 ORM 会把它当成「非结果集响应」，直接跳过后续的SELECT—— 这就是com.microsoft.sqlserver.jdbc.SQLServerException: 该语句没有返回结果集的真实原因 - MySQL 在不支持多结果的驱动下（如旧版
mysql_query()），CALL proc_name后的SELECT会被丢弃，甚至报错ERROR 1312 (0A000): PROCEDURE xxx can't return a result set in the given context - SSMS 里能看见结果，不代表应用能读到——那是 SSMS 主动拉取了所有结果集；而 Java、Python 的默认 cursor 往往只 fetch 第一个，或压根没启用多结果模式
SET NOCOUNT ON 是什么，为什么必须加？
它不是“优化开关”，而是避免结果集被干扰的必要配置。SQL Server 存储过程每执行一条 DML（INSERT/UPDATE/DELETE）都会默认返回一行「(1 行受影响)」消息，这个消息和 SELECT 结果集混在一起，导致客户端无法准确定位真正的数据结果集。
- 不加
SET NOCOUNT ON：执行含INSERT+SELECT的存储过程时，JDBC 会先收到更新计数（getUpdateCount() != -1），然后才轮到getResultSet()，但很多简单封装（比如早期 MyBatis 或手写 DAO）会直接忽略更新计数，导致SELECT被跳过 - 加了之后：所有 DML 不再发影响行数，
SELECT成为唯一可被getResultSet()捕获的结果，行为可预测 - 位置必须在
BEGIN之后、任何语句之前，否则无效；建议作为存储过程第一行固定写法
多个 SELECT 怎么被客户端正确读取？
不是自动拼成一张表，而是按顺序暴露为多个独立结果集，需要显式迭代。多数语言的数据库驱动都提供 getMoreResults() 或等价机制，但默认不会自动遍历全部。
- JDBC 中必须用
do { rs = stmt.getResultSet(); ... } while (stmt.getMoreResults())，漏掉getMoreResults()就只能读第一个SELECT - Python 的
cursor.execute("EXEC proc")后，cursor.fetchall()只取第一个结果；要读后续结果，得调cursor.nextset() - .NET 的
SqlDataReader用reader.NextResult()切换，且每个结果集需单独循环读取 - 注意：如果中间夹了 DML 且没设
SET NOCOUNT ON，这些 DML 的影响行数也会被当作“伪结果集”插入序列，进一步打乱读取顺序
输出参数（OUTPUT）能不能代替 SELECT 返回表格数据？
不能。这是设计层面的硬限制，不是语法技巧能绕过的。
-
@output参数类型只能是标量（INT、VARCHAR(100)、DATETIME等），SQL Server 和 MySQL 都不允许把整张表塞进一个变量里 - 试图写
SET @output = (SELECT * FROM t)会直接报错Subquery returned more than 1 value - 用
FOR XML或FOR JSON把结果转成字符串再赋给@output，看似可行，但实际只适合几条记录；超过 2MB 就可能截断，反序列化成本高，且丢失类型信息 - 真正需要表格数据时，
SELECT是唯一正解；OUTPUT只适合传回统计值、状态码、主键 ID 这类单值
最容易被忽略的一点：即使你确保了 SELECT 存在、加了 SET NOCOUNT ON、也启用了多结果读取，如果存储过程里嵌套调用了另一个带 SELECT 的存储过程，而那个被调用者没设 SET NOCOUNT ON，它的 DML 影响行数仍会污染外层结果流——问题会藏得更深，排查时得逐层检查。
