MySQL 5.7嵌套游标必须显式CLOSE+OPEN，因游标耗尽后不可重用；需分层声明HANDLER、隔离变量名、初始化done标志；优先用INSERT SELECT JOIN替代以提升性能。

MySQL 5.7嵌套游标必须显式CLOSE+OPEN，否则内层只执行一次

根本原因不是语法错，而是MySQL游标状态不可重用：一旦FETCH走到末尾触发NOT FOUND，该游标就进入“耗尽”状态，后续再次FETCH会立刻返回NOT FOUND，不会自动重置。外层循环第二次进入内层时，若没重新OPEN，内层循环直接跳过。

• 每次外层循环体内部，都必须写CLOSE inner_cursor; + OPEN inner_cursor;
• 不能把OPEN放在外层BEGIN前——那只会打开一次
• DECLARE CONTINUE HANDLER FOR NOT FOUND必须在每层循环作用域内单独声明，handler不跨层生效
• 别省略CLOSE：漏关会导致sp_head::main_mem_root内存持续上涨，压测时RSS线性飙升

变量名和done标志必须分层隔离，否则值互相覆盖

MySQL存储过程中DECLARE的变量是过程级作用域，不是块级。三层嵌套如果都用v_id、done这种通用名，后声明的会覆盖前声明的，FETCH取到的永远是最后一层赋的值。

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 给每层变量加前缀，例如一级用cr_id/done_cr，二级用pbr_id/done_pbr，三级用pbp_id/done_pbp
• 所有done_xxx变量必须在OPEN前显式初始化为FALSE，否则未定义行为可能导致无限循环
• 不要在IF或LOOP块内重复DECLARE同名变量——MySQL允许但会静默覆盖，调试时极难定位

用INSERT SELECT替代嵌套游标，90%场景更稳更快

逐行处理是游标本质，也是性能瓶颈来源。嵌套游标下，内层查询被反复执行N×M次；而等价的INSERT ... SELECT ... JOIN是一次集合操作，执行计划复用、索引可下推、IO大幅减少。

• 只要逻辑不涉及函数调用、中间状态累计、条件分支写日志等行级副作用，优先改写为JOIN语句
• 例如“同步主表A → 子表B → 孙表C”，对应INSERT INTO c SELECT ... FROM a JOIN b ON a.id = b.a_id JOIN c_ref ON b.id = c_ref.b_id
• 若需动态计算（如根据A表字段决定插入C表多少行），再考虑游标；否则纯数据搬运类逻辑，游标只是给自己加锁

调试嵌套游标失败时，日志必须写进表，不能靠SELECT输出

MySQL不暴露游标当前行号或位置，SHOW PROCESSLIST也看不到嵌套层级。靠SELECT CONCAT(...)打印调试信息容易被客户端截断、忽略，或因错误中断而没输出。

• 建一张debug_log表，每层循环开头INSERT INTO debug_log(level, outer_id, inner_id, ts) VALUES ('2', cr_id, pbr_id, NOW());
• 每个FETCH后立刻检查done_xxx，并在IF done_xxx THEN INSERT ...里记录“本层结束”，确认是否真走到末尾而非提前退出
• 避免在handler里做复杂操作——GET DIAGNOSTICS比RESIGNAL更可控，防止异常嵌套导致无限递归

真正麻烦的从来不是怎么写嵌套，而是为什么非得嵌套。大多数所谓“三层关联处理”，其实只是没把业务语义翻译成集合操作。游标是最后的手段，不是默认选项。