MySQL存储过程未设退出条件的WHILE循环大概率导致CPU飙至100%、连接不释放、服务卡死；必须配合标签使用LEAVE语句跳出，且须加计数器硬限兜底，防止控制变量未更新引发死循环。
MySQL 存储过程里没设退出条件的 WHILE 循环，大概率会让 CPU 直接飙到 100%，连接卡死、服务假死——这不是理论风险，是线上高频事故。
MySQL 存储过程必须用 LEAVE 而不是 EXIT
很多人写 EXIT 想跳出循环，结果直接报错：EXIT statement not within loop or begin end block with label。MySQL 不支持裸 EXIT，它只认 LEAVE（且必须配合标签）。
-
LEAVE只能在带标签的循环块里用，比如my_loop: WHILE ... DO ... END WHILE;，然后写LEAVE my_loop; - 漏写标签名，或标签名拼错（比如写成
LEAVE my_loopx;），LEAVE就失效，变成静默忽略 - 别用
RETURN替代LEAVE：它会直接退出整个存储过程，跳过后续清理逻辑（比如CLOSE cur），容易导致游标泄漏
WHILE 循环必须配硬计数器兜底
光靠业务逻辑判断退出不靠谱。一旦 SELECT INTO 查不到数据、IF 分支没执行赋值、外部表被锁住，控制变量就卡住不动，WHILE 立刻变死循环。
- 声明计数器和上限：
DECLARE i INT DEFAULT 0;+DECLARE max_iter INT DEFAULT 5000; - 每次循环末尾强制自增：
SET i = i + 1;（别放在 IF 里，否则可能跳过） - 循环开头立刻检查：
IF i >= max_iter THEN LEAVE my_loop; END IF; -
max_iter值不能拍脑袋：按单次调用最大处理行数 × 1.5，再向上取整到千位（比如预估最多 3200 行，就设 5000）
PostgreSQL 和 SQL Server 的退出机制差异很大
PostgreSQL 的 statement_timeout 对纯 PL/pgSQL 死循环（比如 WHILE true LOOP ... END LOOP;）完全无效——它只对内部执行的 SELECT/INSERT 等语句生效；SQL Server 则用 BREAK 退出循环、RETURN 退出过程，但 RETURN 后面的语句不会执行，得自己保证资源释放。
- PostgreSQL 必须靠代码修复：检查
WHILE条件是否恒真、循环体是否真修改了判断变量、游标是否漏了EXIT WHEN NOT FOUND - SQL Server 里
BREAK只跳出当前循环，RETURN会终止整个过程——如果过程里开了事务，RETURN前没ROLLBACK或COMMIT，事务状态就悬着 - 三者都不存在“自动超时中断纯计算”的能力，依赖配置（如
max_execution_time）只是辅助，不是替代
上线前必须验证循环是否真因条件退出
加了计数器不等于问题解决。如果循环跑满 max_iter 才停，说明业务逻辑有缺陷，只是被硬拦住了。
- 循环结束后加诊断语句：
SELECT i, some_condition_variable;，确认i是正常退出（比如i = 482）还是打满上限（i = 5000） - 查
SHOW PROCESSLIST，看状态是不是长期卡在Executing，CPU_time每秒涨几百毫秒——这是死循环正在狂转的铁证 - 别信“测试环境跑得通”，生产数据量、并发、锁竞争会让原本隐蔽的变量更新失败暴露出来
最危险的不是没写 LEAVE，而是写了但控制变量根本没被更新——这种 bug 在日志里不报错、不抛异常，只悄悄吃掉 CPU 和连接数。
