MySQL存储过程WHILE循环必须用LEAVE+显式标签退出，EXIT非法报错；须配计数器硬限防死循环，漏写标签、拼错名或RETURN替代均导致资源泄漏或静默失效。
MySQL存储过程里WHILE循环必须配LEAVE+标签
LEAVE不是可选语法糖，是唯一合法的循环退出方式。写EXIT会直接报错EXIT statement not within loop or begin end block with label，因为MySQL根本不认这个关键字。
实操要点：
- 标签名必须显式声明在
WHILE前，比如my_loop: WHILE condition DO，然后用LEAVE my_loop; - 漏写标签、拼错标签名（如
LEAVE my_loopx;）、或把LEAVE写在IF块末尾却已脱离循环作用域，都会导致静默失效 - 别用
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里statement_timeout拦不住纯计算死循环
statement_timeout只对执行SELECT/INSERT等SQL语句阶段生效，对纯PL/pgSQL的WHILE true LOOP ... END LOOP完全无效——它不消耗查询时间片，超时机制压根不触发。
真正能打断的手段极少：
-
pg_terminate_backend(pid)是唯一可靠方式，但前提是进程没卡死在C函数里（比如缺失CHECK_FOR_INTERRUPTS()） - 递归CTE必须加
CYCLE子句或MAX_RECURSION_DEPTH（PostgreSQL 15+） - 显式游标必须配
EXIT WHEN NOT FOUND，漏写就停不下来 - 检查
WHILE条件是否恒真、循环体是否真修改了判断变量——这两类错误，statement_timeout根本救不了
调试挂起的存储过程，优先查PROCESSLIST而不是等它跑完
MySQL不支持断点，但可以用状态反推卡点位置。别等它自己结束，主动查它正在干啥。
实操步骤：
- 新开会话执行
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 60;，找出长时间运行的连接 - 记下ID后执行
KILL [ID];强制中断，验证是否真卡在循环里 - 在存储过程中关键位置插
SELECT 'step 1';这类标记（注意调用方要能接收多结果集） - 循环内加
SELECT CONCAT('i=', i);打点观察变量变化，比脑补靠谱得多
跑满max_iter才停，说明业务逻辑有缺陷，只是被硬拦住了；真正难的是让所有人坚持同一套标签命名、计数器写法和退出检查节奏——漏掉一个环节，死循环就在高并发时重现。
