SQL Server存储过程支持多条SELECT返回多个结果集，按语句顺序严格输出，客户端需用NextResult()或nextset()逐个读取，空结果集仍存在但行数为0，须显式跳转否则后续结果集无法访问。
SQL Server存储过程里写多条SELECT就能返回多个结果集
能。SQL Server原生支持在同一个存储过程中用多条SELECT语句返回多个结果集，不需要额外声明、临时表或游标。客户端（如C#的SqlDataReader、Python的pyodbc）通过调用NextResult()或nextset()逐个读取，每执行一次就跳到下一个结果集。
多结果集的顺序和结构完全由SELECT语句顺序决定
SQL Server严格按存储过程中SELECT出现的先后顺序返回结果集，不合并、不重排。每个结果集独立拥有自己的列名、数据类型和行数。
- 列名以
SELECT中定义的别名或原始字段名为准，不同SELECT间列名可以重复或完全不同 - 同一结果集内列数必须固定，但不同结果集之间列数、类型、顺序均可不同
- 如果某条
SELECT返回空结果（0行），该结果集仍存在，只是HasRows为false或rowcount == 0 - 注意：带
ORDER BY只影响本结果集排序，不影响其他结果集
常见错误：WHERE条件漏写或逻辑错位导致结果集“消失”
最常被忽略的是——某条SELECT因WHERE条件过严、参数未传入、JOIN失败等原因实际没返回任何行，开发者误以为“那个结果集没出来”，其实是出来了，只是空的。调试时容易误判流程逻辑。
- 在SSMS中执行存储过程时，会看到多个结果网格，哪怕某个是空的，也能看到标题栏
- C#中用
SqlDataReader读取时，即使第一个SELECT为空，reader.Read()返回false，但必须调用reader.NextResult()才能进入第二个结果集，否则卡住 - Python +
pyodbc同理：cursor.fetchall()对空结果集返回空列表[]，但必须显式调用cursor.nextset()才能切换 - 避免用
IF EXISTS(SELECT...)包裹SELECT——这会让结果集变成条件分支，而不是稳定输出
性能与兼容性：不增加网络往返，但客户端必须主动处理
多个结果集走的是同一次RPC调用，不会像多次EXEC那样触发多次网络往返，理论上更高效。但代价是客户端代码必须适配多结果集协议，否则只能拿到第一个结果集。
- .NET Framework 4.5+ 的
SqlDataReader原生支持，无需额外配置 - Java的JDBC驱动需开启
multipleActiveResultSets=true（MARS），且SQL Server实例要启用MARS支持 - Node.js的
mssql包默认支持，但需用request.stream = true并监听row/done事件链 - 注意：某些ORM（如Entity Framework Core早期版本）不自动解析多结果集，需手动调用
DbCommand.ExecuteReader()
真正麻烦的不是写多少个SELECT，而是确保每个结果集的语义清晰、列结构稳定，并且客户端不漏掉NextResult()这类关键跳转调用——少一次，后面所有结果集都读不到。
