MySQL存储过程能输出多个结果集，但需显式启用multipleStatements=true连接参数，且客户端必须用CallableStatement.execute()配合getMoreResults()循环读取，否则第二个SELECT会被静默丢弃或触发ERROR 1312。
MySQL 存储过程本身能输出多个结果集，但“无法直接返回”是客户端、驱动、协议三者共同限制的结果——不是语法不支持，而是通道默认关着，且容易被中间层吃掉。
为什么写了两个 SELECT 却只收到第一个结果集
根本原因是 MySQL 协议默认把 CALL 当作单语句执行，后续结果集不被主动拉取。即使存储过程里写了 SELECT a; SELECT b;，第二个结果集也会被静默丢弃，甚至触发 ERROR 1312 (0A000): PROCEDURE xxx can't return a result set in the given context。
-
multipleStatements=true必须显式开启（JDBC 加 URL 参数，Node.js mysql2 设multipleStatements: true），否则协议层直接截断 - 旧版 PHP 的
mysql_query()、某些 ORM 封装（如早期 MyBatis 的selectOne）默认只处理首个结果集，后续调用不触发nextset()就永远读不到 - MySQL 8.0+ 在云数据库 Proxy（如阿里云 RDS Proxy、腾讯云 CVM 中间件）下可能彻底拒绝多结果，需实测确认是否透传
COM_STMT_EXECUTE后的多包响应
CALL 调用时哪些客户端行为会导致结果集丢失
不是所有 CALL 都等价。客户端用错执行方法，等于没开通道。
- Java 用
executeQuery("CALL ...")：强制走单结果路径，第二个SELECT直接被忽略 - 必须改用
CallableStatement.execute()+ 循环getMoreResults()，漏掉任意一次getMoreResults()调用，后续结果集就不可达 - Python 的
cursor.execute("CALL ...")后，fetchall()只取第一个；得手动调cursor.nextset()才能跳转 - Laravel 的
DB::select()底层走的是PDO::query()，不自动遍历多结果集，必须换用原生 PDO 或扩展包（如rodion-arr/laravel-mysql-stored-procedures）
为什么不能像 SQL Server 那样“天然支持”
SQL Server 把多结果集作为核心协议能力暴露，而 MySQL 是靠 multipleStatements “借道”实现的——它本质复用了“执行多条语句”的机制，不是专为存储过程设计的返回通道。
- SQL Server 的
SET NOCOUNT ON是清理干扰项，MySQL 没这层干扰，但也没有对应的协议级结果集标记 - MySQL 存储过程里的
SELECT是“输出动作”，不是“返回值”，所以不能嵌套在表达式中（比如不能SELECT * FROM (CALL p())） - PostgreSQL 根本不提供该能力，只能用
refcursor模拟；MySQL 的多结果集已是相对最宽松的方案，但依赖生态配合
真正卡住多数人的，从来不是怎么写存储过程，而是连接参数漏设、驱动调用方式写错、或云环境 Proxy 拦截——这些点一旦出问题，SELECT 写得再对也白搭。
