能，sql server原生支持存储过程中多个select按顺序返回多个独立结果集；需加set nocount on、避免中断语句，并由客户端显式调用nextresult()或nextset()逐个读取，空结果集仍存在但hasrows为false。
SQL Server 存储过程里多个 SELECT 真的能返回多个结果集吗
能，而且是原生支持。只要在存储过程中按顺序写多个 SELECT 语句，SQL Server 就会严格按顺序把每个 SELECT 的结果作为独立结果集发回客户端。不需要游标、临时表或特殊声明。
但必须加 SET NOCOUNT ON 开头，否则每条语句后的 “X 行受影响” 消息会被客户端误认为是结果集，导致解析错乱。中间也不能有未捕获的错误、RETURN 或 THROW，否则后续 SELECT 根本不执行。
常见误区：
- 看到 SSMS 里某个结果网格为空，就以为“那个结果集没出来”——其实是出来了，只是
HasRows == false - 用
IF EXISTS(SELECT ...)包裹SELECT，结果变成条件分支，破坏了稳定输出结构 - 在 MySQL 或 PostgreSQL 里照搬写法，发现只拿到最后一个结果集——它们协议不支持该语义
C# 中 SqlDataReader 怎么读完所有结果集
SqlDataReader.Read() 只读当前结果集的行，不会自动跳到下一个。漏掉 NextResult()，就永远卡在第一个结果集。
正确做法是显式循环切换：
- 先用
while (reader.Read())处理第一个结果集全部行 - 再调
if (reader.NextResult())判断并进入第二个；重复直到返回false - 更稳妥写法是
do { ... } while (reader.NextResult());，避免漏掉最后一个 - 即使某个
SELECT返回空（reader.Read()直接返回false），也必须调一次NextResult()才能进下一个
典型错误：while (reader.Read()) { ... } —— 这只会处理第一个结果集的所有行，其余全丢。
Python + pyodbc 怎么安全调用 nextset()
cursor.nextset() 是关键，但它有硬性前提：上一个结果集的数据必须被“消费”过，哪怕只调一次 fetchone() 或 fetchall()。
直接 cursor.nextset() 会报错：ProgrammingError: No results. Previous SQL was not a query.
注意点：
-
nextset()返回None表示还有下一个，返回False表示到底了——别用is True判断 - 空结果集时
cursor.fetchall()返回[]，不影响后续nextset() - 推荐模式：
while True:→rows = cursor.fetchall()→if not cursor.nextset(): break
MySQL 的 pymysql 和 PostgreSQL 的 psycopg2 不支持 nextset()，这个方法仅限 SQL Server + pyodbc 场景。
EF Core 和 Dapper 能不能直接用多结果集
不能原生支持。ORM 层的设计假设是“一次调用 → 一个强类型结果”，而多结果集天然打破这个契约。
具体表现：
- EF Core 默认只取第一个结果集；
FromSqlRaw().AsSplitQuery()是模拟，不是真多结果集 - Dapper v2+ 提供
QueryMultiple()，但要求你提前知道有几个结果集、各自结构，并手动调Read<t1>()</t1>、Read<t2>()</t2> - 最可靠方式仍是绕过 ORM，用
DbCommand.ExecuteReader()手动处理——但也意味着放弃映射、变更跟踪等便利
跨语言或升级驱动时，NextResult()/nextset() 行为可能变化，而这种问题往往静默丢数据，上线后才暴露。这点最容易被忽略。
