MySQL存储过程中游标循环内SELECT无输出，因非交互式上下文会静默丢弃结果集；应使用CREATE TEMPORARY TABLE配合INSERT记录调试信息，并用CONTINUE HANDLER容错。
为什么不能直接用 SELECT 在游标循环里调试
MySQL 存储过程中，SELECT 语句在非交互式上下文（比如通过应用调用或定时事件触发）不会返回结果集，只会被静默丢弃。你看到“没输出”，不是逻辑错了，而是 MySQL 根本不给你看——这和在客户端手动执行 SELECT 完全不是一回事。
临时表是唯一可靠、可追溯、不干扰原逻辑的调试载体。它能保留每轮循环的中间状态，且生命周期绑定会话，无需清理残留（会话结束自动释放）。
- 必须用
CREATE TEMPORARY TABLE，不能用普通表（否则并发调用会冲突） - 字段设计要包含序号（
step_id）、时间戳（created_at）、关键变量值（如cur_id、cur_name）、错误标记（error_msg） - 避免在循环内反复
DROP或CREATE临时表——只建一次，INSERT多次
如何在游标循环中安全插入调试记录
核心原则：把调试写入和业务逻辑解耦，防止因调试语句报错导致主流程中断。最稳妥的方式是用 INSERT ... SELECT 或显式 INSERT，并包裹 DECLARE CONTINUE HANDLER 捕获可能的约束冲突（比如重复插入同一 step_id）。
示例片段：
DECLARE CONTINUE HANDLER FOR SQLSTATE '23000' -- 忽略重复键等非致命错误 BEGIN END; <p>INSERT INTO debug_cursor_log (step_id, created_at, cur_id, cur_name, processed) VALUES (@step_counter, NOW(), @cur_id, @cur_name, @processed_flag);
-
@step_counter要在循环外初始化为 0，并在每次循环开头SET @step_counter := @step_counter + 1 - 不要用
SELECT ... INTO的结果直接插进调试表——若查询无结果，变量会变成NULL，容易掩盖真实值 - 如果游标本身基于复杂子查询，建议先将游标声明的
SELECT单独拿出来执行一遍，确认数据量和 NULL 分布
调试表字段设计与查询技巧
临时表字段不是越多越好，但必须覆盖定位问题的关键维度。常见漏掉的是“是否进入循环体”和“是否触发异常退出”。
- 必加字段：
id INT AUTO_INCREMENT PRIMARY KEY（方便按插入顺序排序）、step_id INT（人工步数标记）、event_type VARCHAR(20)（值为'fetch'/'process'/'exit'） - 游标 fetch 后立刻记录一行
event_type = 'fetch'，再做业务处理；处理完再记一行event_type = 'process'，这样能区分是取数失败还是处理失败 - 查调试记录时用
SELECT * FROM debug_cursor_log ORDER BY id DESC LIMIT 50，而不是按step_id——因为异常中断后step_id可能不连续 - 别忘了在存储过程末尾加一句
SELECT * FROM debug_cursor_log;，这是你唯一能看到结果的地方
容易被忽略的隔离与并发陷阱
临时表虽会话级隔离，但如果你在存储过程中嵌套调用了另一个含调试逻辑的过程，或者用 CALL 多次触发同一过程，就会出现调试表被覆盖或混杂的问题。
- 每次调用前，用
DROP TEMPORARY TABLE IF EXISTS debug_cursor_log;确保干净起步 - 不要依赖
CONNECTION_ID()做表名后缀——临时表名不支持变量拼接，硬拼会导致语法错误 - 如果过程被事件调度器调用，务必确认
event_scheduler使用的是独立连接，否则调试表可能被其他会话操作干扰 - 最隐蔽的问题：某些 ORM（如 Laravel 的 DB::statement）会复用连接但不清除临时表，第二次调用时
CREATE TEMPORARY TABLE报错Table 'debug_cursor_log' already exists——必须加IF NOT EXISTS
调试游标真正难的不是写 INSERT，而是判断哪一行数据该信、哪一行是残留、哪一行因变量作用域混乱而失真。多打一行 event_type，比多猜十分钟强。
