SQL Server存储过程天然支持返回多个结果集，但需每个SELECT显式声明列名与类型以确保客户端正确识别结构；临时表或SELECT *会导致元数据不可见，应避免。
SQL Server 存储过程如何返回多个带结构的结果集
SQL Server 的存储过程天然支持返回多个结果集，但“带结构说明”不是自动附带的——客户端能否正确识别每个结果集的列名、类型、可空性等元数据，取决于你是否显式提供可推断的结构。关键在于：每个 SELECT 语句必须有明确的列定义（不能是 SELECT *），且避免在同一个过程中混用临时表+无列别名的动态投影。
- 使用
SELECT col1 AS name1, col2 AS name2 FROM ...显式声明列名和别名，而非SELECT * - 若需返回空结果集占位（如条件分支中某分支不查数据），用
SELECT NULL AS col1, '' AS col2 WHERE 1=0，确保列结构存在 - 避免在同一个存储过程中先
SELECT再INSERT INTO #t EXEC sp_executesql后又SELECT * FROM #t—— 临时表列元数据在编译期不可见，客户端可能收不到结构 - SQL Server 2016+ 可配合
WITH RESULT SETS在调用侧强制指定结构，但这是调用方行为，不改变存储过程本身输出
MySQL 存储过程中返回多结果集的限制与绕过方法
MySQL 存储过程不支持直接返回多个结果集给客户端——CALL 语句最多只返回一个结果集（即最后一个 SELECT）。所谓“多结果集”，实际是伪需求，必须换思路实现。
- 把多个逻辑结果拼成单个宽表：用
UNION ALL连接不同查询，但要求列数、类型兼容，且需加标识列区分来源（如SELECT 'users' AS source_type, id, name FROM users） - 用 JSON 汇总：MySQL 5.7+ 支持
JSON_OBJECT和JSON_ARRAYAGG，将各查询结果分别转为 JSON 字段，例如SELECT JSON_ARRAYAGG(JSON_OBJECT('id',id,'name',name)) AS users_data, JSON_ARRAYAGG(JSON_OBJECT('order_id',order_id)) AS orders_data FROM DUAL - 放弃存储过程，改用视图组合或应用层分多次
SELECT—— 更可控，也更符合 MySQL 的设计约束
PostgreSQL 中用 REFCURSOR 返回多个命名结果集
PostgreSQL 不允许存储过程（PROCEDURE）直接返回结果集，但函数（FUNCTION）可以返回 SETOF 或 REFCURSOR。要返回多个结构化结果集，REFCURSOR 是标准解法：它把游标名作为输出参数，客户端通过名称分别获取。
- 函数定义需包含多个
OUT ref1 refcursor, ref2 refcursor参数，并在函数体内用OPEN ref1 FOR SELECT ...分别绑定查询 - 每个
OPEN对应的SELECT必须有确定列结构（列名+类型），否则客户端拿到的是泛型record，无法解析字段 - 调用时需先
BEGIN; SELECT * FROM your_func(); FETCH ALL IN "ref1"; FETCH ALL IN "ref2"; COMMIT;—— 游标生命周期绑定事务，不能跨事务获取 - 注意：JDBC/ODBC 驱动对多
REFCURSOR的支持程度不一，pgJDBC 42.2+ 支持，但需启用cursorFetchSize并手动处理多个ResultSet
客户端如何稳定读取多结果集的结构信息
即使服务端正确输出了多个结果集，客户端仍可能因驱动或 API 使用不当丢失列元数据。核心问题不在 SQL，而在获取方式。
- 不要用
ExecuteScalar()或ExecuteNonQuery()调用多结果集存储过程 —— 它们会丢弃后续结果集 - .NET 中必须用
SqlDataReader.NextResult()主动跳转，并在每个结果集上调用GetSchemaTable()获取列定义 - Python 的
psycopg2需在cursor.execute()后循环调用cursor.fetchall()，但要注意：只有第一个结果集能通过cursor.description获取结构，后续结果集需依赖cursor.nextset()后重新检查description - 结构信息缺失最常见原因：中间件（如连接池、ORM）自动消费了第一个结果集后未继续轮询，或错误地把多结果集当异常处理
多结果集的结构稳定性，80% 取决于服务端每条 SELECT 的确定性，剩下 20% 取决于客户端是否严格按协议逐个拉取并检查 description。临时表、动态 SQL、列别名缺失，任何一个环节松动，结构就不可靠。
