能，判断是否触发多结果集需确认执行语句类型：call存储过程、启用multiplestatements的复合sql（含分号分隔）、或ddl+dml组合；这些均可能返回多个结果集（含数据集、状态包、影响行数等），须循环清理直至无剩余。
必须先确认是否执行了多结果集语句（如 CALL、含多个分号的 SQL、SELECT 后跟 INSERT 等），否则直接跳过所有“清空结果集”的操作，排查方向就错了。
怎么判断当前查询触发了多结果集？
MySQL 在执行存储过程（CALL）、启用了 CLIENT_MULTI_STATEMENTS 的复合语句、或某些 DDL+DML 组合时，会返回一个或多个结果集 —— 不仅包括你 SELECT 的数据，还可能包含状态包（OK/ERR）、影响行数、警告信息等。这些都算“结果集”，哪怕内容为空。
常见触发场景：
-
CALL proc_name()：哪怕过程里只有一条SELECT，也会至少返回两个结果集（数据集 + 过程执行状态） -
SELECT * FROM t1; INSERT INTO t2 VALUES (1)：用mysql_real_query()或mysqli::multi_query()执行时，分号被识别为语句分隔符 -
SHOW CREATE TABLE t1; -- 注释：末尾带分号 + 注释，部分驱动（如旧版 MySQLdb）会误判为多语句
不同语言/驱动下必须做的清理动作
核心原则：只要一次执行可能产生多个结果集，就必须循环调用获取 + 释放，直到无剩余结果。不能只处理第一个。
各驱动关键操作：
- C API：
mysql_store_result()取当前结果 →mysql_free_result()释放 → 循环mysql_next_result()返回 0 表示还有 → 重复前两步，直到返回非 0 - PHP mysqli：
mysqli::multi_query()后，必须用mysqli::next_result()+mysqli::use_result()或mysqli::store_result()配对清理，不能只用query() - Python MySQLdb / PyMySQL：
cursor.execute()前确保上一个语句已完全消费；若执行了CALL，需手动调用cursor.nextset()直到返回False - Java Connector/J：
Statement.execute()返回true表示有结果集，需getResultSet()；之后反复调用getMoreResults()直到返回false
容易被忽略的“假安静”陷阱
有些错误看起来不报错，但连接已处于脏状态：比如执行 CALL 后只取了第一个结果集、没调 nextset() 或 mysql_next_result()，后续任意语句（哪怕只是 SELECT 1）都会触发 CR_COMMANDS_OUT_OF_SYNC（错误码 2014）。
这类问题在连接复用（连接池）场景下尤其隐蔽 —— 错误不发生在出问题的那行代码，而是在下一次从池中取出该连接时才暴露。
调试建议：
- 开启 MySQL general log（
SET GLOBAL general_log = ON），对照客户端调用顺序看服务端实际收到了什么、返回了几组包 - 在每次执行可能多结果的语句后，强制加一段清理逻辑（即使你“确定”只有一个结果集），比事后追查更省时间
- 避免在同一个连接上混用
mysql_use_result()和mysql_store_result()—— 两者缓冲策略冲突，极易引发同步错乱
真正麻烦的不是“怎么修”，而是“什么时候想起来要修”：只要涉及 CALL、分号分隔、或任何非单 SELECT/INSERT 场景，就得默认它可能带隐藏结果集。
