WHILE循环陷入死循环的主因是循环变量未更新或更新不可靠：变量未在循环体中修改、仅在分支内更新导致跳过，或用易被并发干扰的业务字段作终止条件；LEAVE语句因标签缺失、错误或位置不当而失效。
WHILE循环条件始终为真，变量没更新
最常见的情况是：循环变量在循环体里根本没被修改，或者只在某个分支里改了，而其他路径跳过了它。比如 SET i = i + 1 写在 IF ... THEN 块里，但条件不满足时这行就永远不会执行——i 停滞不动，条件永远成立。
实操建议：
- 把
SET i = i + 1放在循环体末尾、所有分支之外，确保每次迭代必执行 - 避免用业务字段（如
@max_id）做终止条件，它可能被并发写入干扰，导致永远追不上 - 用
SELECT CONCAT('i=', i);在循环开头打点，亲眼确认变量是否在变
LEAVE语句失效，标签名或作用域出错
LEAVE 不是万能钥匙——它只能跳出**紧邻的、带标签的循环块**，且标签名必须完全一致（大小写敏感、不能多空格、不能漏写）。漏标签、写错名、或把 LEAVE 放到 END IF 后面，都会让它静默失效。
实操建议：
- 给
WHILE加显式标签，比如my_loop: WHILE i -
LEAVE必须写成LEAVE my_loop;，不能只写LEAVE; - 标签必须紧贴
WHILE前，中间不能有空行或注释 - 嵌套循环时，内层
LEAVE只能跳内层，想跳外层得写外层标签名
游标配合WHILE时，done变量被意外重置
典型陷阱：声明 DECLARE done INT DEFAULT 0;，再配 DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;。一旦游标取完数据，done 变成 1，但后续循环中如果没重置它，WHILE done = 0 就永远进不去；更糟的是，有人写成 WHILE done ，而 <code>done 被 handler 设成 1 后，1 恒真，直接死循环。
实操建议：
- 游标循环推荐用
WHILE NOT done DO，初始done是FALSE（即0），fetch 后才可能变TRUE - 别拿
done当计数器用——它只是“是否取完”的信号，不是循环次数 - 如果非要混用，每次 fetch 后手动检查
done，并在LEAVE前确认状态
循环体里发生错误，SET语句没执行就退出
比如 INSERT 违反唯一约束，又没定义 CONTINUE HANDLER，整个存储过程直接报错中断——SET i = i + 1 根本没机会跑，下次调用时 i 还是老值，条件照旧成立。
实操建议：
- 关键递增语句（如
SET i = i + 1）放在循环最开头或最末尾，避开可能出错的 SQL 块 - 对可能失败的操作加
CONTINUE HANDLER，至少保证计数器能推进 - 别依赖
max_execution_time——它对存储过程内部逻辑无效，死循环会一直占连接
LEAVE 没跳出正确标签，或者 done 被 handler 和业务逻辑反复覆盖，照样卡住。动手前先想清楚：这个变量在哪改、在哪读、谁负责重置。 
