SQL Server存储过程支持多个SELECT返回多结果集，但需用NextResult()等专用方法逐个获取；MySQL/PostgreSQL不原生支持，EF因类型映射限制默认不支持，须手动DbCommand或JSON折中。
SQL Server 存储过程中怎么拿到多个 SELECT 的结果
SQL Server 存储过程允许写多个 SELECT 语句，但客户端是否能拿到、怎么拿，取决于调用方式和驱动支持。不是所有语言或 ORM 都默认处理多结果集，直接用 ExecuteNonQuery() 或普通查询方法会只取第一个结果，后面全丢掉。
- 必须用支持多结果集的执行方式：比如 .NET 的
SqlDataReader.NextResult()，Python 的cursor.nextset()，Java 的Statement.execute()+getResultSet()循环 - 不能用
ExecuteScalar()或ExecuteReader()（不带循环）——它们只读第一个结果 - EF Core 默认不支持多结果集，得用
DbCommand手动执行；Dapper 从 v2 起支持QueryMultiple() - 如果中间某个
SELECT返回空结果（0 行），NextResult()仍会成功跳转，不会报错，但后续Read()返回false
MySQL / PostgreSQL 存储过程里写多个 SELECT 有用吗
基本没用。MySQL 的存储过程不支持返回多个结果集给客户端（即使写了多个 SELECT，只有第一个会被客户端收到）；PostgreSQL 的 FUNCTION 如果返回 SETOF 或多个 RETURN QUERY，本质是合并成一个结果集流，不是独立的“结果集组”。真要多结果，得靠应用层拆解或改用临时表 + 多次查询。
- MySQL 8.0+ 的
CREATE PROCEDURE中多个SELECT会被忽略（除第一个外），甚至可能触发警告Warning: 1312 - PROCEDURE ... can't return a result set in the given context - PostgreSQL 想模拟多结果，得用
REFCURSOR输出参数，再由客户端分别FETCH，但这是“伪多结果”，实际仍是单连接上的多次交互 - 跨数据库移植时，这种写法几乎必然失败，别当通用方案用
为什么 Entity Framework 不让直接调用多结果集的存储过程
EF 的设计假设是“一次调用 → 一个结果类型”，映射关系绑定在方法签名上。多个 SELECT 意味着可能返回不同结构的数据，EF 没法静态推导类型，也没法生成对应实体映射。
- EF6 用
ObjectContext.ExecuteFunction()可以，但需提前定义每个结果集的ComplexType，且仅限 SQL Server - EF Core 5+ 提供了
FromSqlRaw().AsMultipleResults()实验性 API，但稳定版仍推荐绕过 EF，用Database.GetDbConnection()拿原生DbCommand - 如果硬要用 EF 映射，常见折中：把多个结果集拼成 JSON 字符串返回，再在 C# 里反序列化——但这把结构化压力转给了应用层，也失去数据库端的类型安全
容易被当成“多结果”实则只是单结果拼接的坑
很多人以为 UNION ALL 或 CTE + SELECT 多个分支就是多结果集，其实不是。这些都属于单语句、单结果集，只是行数多或列结构一致。真正的多结果集是多个独立的 SELECT 语句，各自有独立的列名、列数、数据类型。
-
SELECT a FROM t1; SELECT b, c FROM t2;→ 真多结果（SQL Server 支持） -
WITH x AS (...) SELECT * FROM x UNION ALL SELECT * FROM y;→ 单结果，列数/类型必须兼容 - 用
INSERT INTO #tmp EXEC proc_name捕获第一个结果，但后面的 SELECT 依然丢失——临时表只能接住一个结果集 - SSMS 里能看到多个结果网格，但那是客户端 UI 的聚合展示，不代表程序里能自动遍历
多结果集不是语法糖，是连接协议层的能力。它省了一次网络往返，但也锁死了调用链路的控制粒度——你得自己管理每个结果集的读取顺序、异常位置和资源释放。稍不注意，漏掉 NextResult() 就卡死连接，或者某次 Read() 忘了判断返回值就崩掉。
