sql server 存储过程支持多select返回多个结果集，但客户端必须显式调用nextresult()（c#）或nextset()（python）切换，且需先消费当前结果集；orm如ef core不原生支持，dapper需querymultiple()手动处理。
SQL Server 存储过程里写多个 SELECT 就能返回多个结果集，但前端应用程序默认只能拿到第一个——这不是数据库限制，而是客户端没主动切换结果集游标。
SQL Server 中多 SELECT 确实能返回多个结果集
只要在存储过程中按顺序写多个 SELECT，SQL Server 就会原生支持返回多个独立结果集：
- 每个
SELECT对应一个结果集，列名、类型、行数互不影响 - 空结果集（0 行）也存在，只是
HasRows为 false 或rowcount == 0 - 必须加
SET NOCOUNT ON开头，否则每条语句后的 “X 行受影响” 消息会干扰结果集解析 - 中间不能有未捕获的错误、
RETURN或THROW，否则后续SELECT不执行
C# SqlDataReader 必须显式调用 NextResult()
SqlDataReader.Read() 只读当前结果集的行，不会自动跳转。漏掉 NextResult() 就永远卡在第一个结果集：
PigX UI 前端开发
下载
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
- 错误写法：
while (reader.Read()) { ... }→ 只处理第一个结果集所有行 - 正确流程：先
while (reader.Read())读完第一个；再if (reader.NextResult())切换；重复 - 更稳妥写法：
do { ... } while (reader.NextResult());，避免漏掉最后一个 - 即使某个
SELECT返回空，NextResult()仍返回 true，必须调用才能进下一个
Python pyodbc 要用 nextset() 且注意 fetch 顺序
cursor.nextset() 是关键，但它有个硬性前提：上一个结果集的数据必须被“消费”过（哪怕只调一次 fetchone() 或 fetchall()）：
- 直接
cursor.nextset()报错：ProgrammingError: No results. Previous SQL was not a query. - 空结果集时
cursor.fetchall()返回[]，不影响后续nextset() -
nextset()返回None表示还有下一个，返回False表示到底了——别用is True判断 - MySQL / PostgreSQL 的驱动不支持这个协议，
nextset()在它们上面根本不存在
EF Core 和 Dapper 的适配成本容易被低估
ORM 层天然不匹配多结果集语义，强行用会绕过类型安全和映射机制：
- EF Core 默认只取第一个结果集；
FromSqlRaw().AsSplitQuery()是模拟，不是真多结果集 - Dapper v2+ 提供
QueryMultiple()，但要求你提前知道有几个结果集、各自结构，并手动Read<t1>(), Read<t2>()</t2></t1> - 用
DbCommand.ExecuteReader()手动处理是最可靠方式，但也意味着放弃 ORM 的大部分便利 - 跨语言或升级驱动时，
NextResult()/nextset()行为可能变化，而这种问题往往静默丢数据，上线后才暴露
真正麻烦的不是怎么写存储过程，而是确保每一层客户端代码都严格遵循“读完再跳”的顺序——少一次 NextResult() 或漏掉一次 fetchall()，后面的结果就永远收不到。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
