postgresql不能直接返回多个结果集，必须用refcursor模拟：函数声明out refcursor参数，begin事务后open游标并命名，调用方在同事务中fetch all in逐个获取；游标名大小写敏感且仅事务内有效。
能，但必须分数据库看——SQL Server 原生支持，MySQL 需显式启用且版本 ≥ 5.7，PostgreSQL 则根本不能直接返回，得靠 refcursor 模拟。
SQL Server：多个 SELECT + SET NOCOUNT ON 是硬性组合
只要存储过程里写多个 SELECT，SQL Server 就会把每个都当一个独立结果集发回去。但漏掉 SET NOCOUNT ON，客户端会把 “(12 行受影响)” 这类消息当成结果集，解析直接错乱。
-
SET NOCOUNT ON必须放在BEGIN后第一行，不能晚于任何SELECT - 中间不能有未捕获的
THROW或RETURN，否则后续SELECT根本不执行 - 用
IF EXISTS(...)包裹某个SELECT，会导致该分支跳过时“缺一个结果集”，调用方按固定顺序读就会崩 - C# 里必须用
do { ... } while (reader.NextResult());，不是while (reader.Read())
MySQL：multipleStatements=true + execute() 才能触发多结果
MySQL 存储过程写多个 SELECT 确实能返回多结果集，但默认被协议拦截——你看到的只是第一个，第二个静默丢弃，甚至报 Warning 1312。
- 连接参数必须设
multipleStatements=true（JDBC URL 加?multipleStatements=true，Node.js mysql2 设multipleStatements: true） - Java 必须用
CallableStatement.execute()启动，再循环调getMoreResults()；不能用executeQuery("CALL ...") - Node.js 的
connection.query('CALL ...', cb)回调里，results是数组，results[0]是第一个结果集，results[1]是第二个 - MySQL 8.0+ 在某些云数据库 Proxy 下会直接拒绝多结果，得实测确认底层协议是否透传
PostgreSQL：没有“多结果集”这回事，只有 refcursor 游标链
你写十个 SELECT，PostgreSQL 只返回最后一个。真要模拟，只能用 refcursor——它不是数据，只是一个命名句柄，真正的查询在 FETCH 时才执行。
- 函数必须声明为
RETURNS record或SETOF refcursor，且每个OUT参数类型是refcursor - 调用前必须
BEGIN开事务，否则FETCH ALL IN "xxx"报错cursor "xxx" does not exist -
OPEN users_cursor FOR SELECT ...中的users_cursor是名字，后续FETCH必须完全一致（大小写敏感） - 函数调用本身（如
SELECT * FROM get_user_and_order_cursors()）只打开游标、返回名字，不查数据；FETCH才真正执行
Dapper QueryMultiple 是最省心的跨库方案
如果你用 .NET + Dapper，别纠结存储过程怎么写，直接拼 SQL 批处理更稳：QueryMultiple 内部自动适配各数据库的多结果协议，比手撸 refcursor 或 JDBC getMoreResults() 直观得多。
- SQL 字符串里写多个
SELECT，顺序就是读取顺序，multi.Read<user>()</user>→multi.Read<order>()</order>一一对应 - 不要在 SQL Server 存储过程中加
SET NOCOUNT ON，Dapper 解析依赖“消息分隔”，加了反而可能跳过结果集 - 某结果集为空，
Read<t>()</t>返回空集合，不抛异常；但若想跳过第三个结果集，得显式调multi.Skip()，否则后续读取会偏移 - 列名必须严格匹配目标类型属性名，Dapper 按名映射，不按位置
最容易被忽略的是事务边界和游标生命周期——PostgreSQL 的 refcursor 一旦 COMMIT 就失效，MySQL 的 multipleStatements 在连接池复用时可能残留状态，SQL Server 的 NOCOUNT 若漏写，错误不会报在存储过程里，而是在客户端解析阶段静默错位。
