PL/SQL WHILE循环需显式更新循环变量，否则将无限执行；必须设最大尝试次数、超时机制和监控手段，并警惕自治事务导致的隐式提交与数据不一致风险。
PL/SQL WHILE循环的终止条件必须在循环体内显式修改
while 循环不会自动推进，exit when 也不是必需的——但只要循环变量不被修改，就会卡死。常见错误是把判断逻辑写在 while 子句里，却忘了在循环体中更新它。
比如用 i 控制次数，却只在开头赋值一次：
DECLARE
i NUMBER := 1;
BEGIN
WHILE i <= 5 LOOP
DBMS_OUTPUT.PUT_LINE('当前i=' || i);
-- 忘了 i := i + 1;
END LOOP;
END;结果就是无限输出“当前i=1”。
- 循环变量必须在每次迭代中被明确赋值（
i := i + 1、cnt := cnt - 1等） - 不能依赖外部过程或函数副作用来改变条件变量
- 如果条件依赖查询结果（如
SELECT COUNT(*) INTO n FROM t WHERE ...），务必确保该查询结果会随循环进展而变化，否则也等价于死循环
WHILE和LOOP...EXIT WHEN混用时，优先用EXIT WHEN控制退出逻辑
WHILE 的条件只在每次循环**开始前**检查；而 EXIT WHEN 可以插在循环体任意位置，更适合复杂退出场景（比如处理异常、提前满足业务条件、或需要执行清理动作后再退出）。
例如读取游标时，常需先 FETCH 再判断是否结束：
OPEN cur; LOOP FETCH cur INTO rec; EXIT WHEN cur%NOTFOUND; -- 这里不能用 WHILE cur%FOUND -- 处理 rec END LOOP; CLOSE cur;
- 用
WHILE cur%FOUND是错的：第一次还没FETCH，%FOUND 是 NULL，循环直接跳过 -
EXIT WHEN放在FETCH后，语义清晰且安全 - 混合使用时，避免同时用
WHILE和EXIT WHEN做同一类判断（比如既写WHILE i 又在中间 <code>EXIT WHEN i >= 10），容易逻辑重叠或遗漏
PL/SQL WHILE循环没有内置超限保护，需手动加计数器或超时兜底
数据库不会主动中断看似失控的 WHILE，一旦逻辑出错，可能耗尽会话资源、锁表、甚至拖慢整个实例。开发时得自己设防。
- 对不确定迭代次数的场景（如重试、轮询、树遍历），强制加最大尝试次数：
max_attempts CONSTANT PLS_INTEGER := 100;，并在循环中检查attempts > max_attempts - 涉及远程调用或等待（如
DBMS_ALERT.WAITONE）时，必须配timeout参数，并用EXIT WHEN timeout_occurred - 长时间运行的循环建议嵌入
DBMS_APPLICATION_INFO.SET_SESSION_LONGOPS，方便 DBA 监控，但这不是防死循环，只是辅助定位
WHILE循环内执行DML后，注意事务边界与隐式提交风险
PL/SQL 中 WHILE 本身不开启或关闭事务，但循环体内若调用自治事务（AUTONOMOUS_TRANSACTION）函数、或触发隐式提交的 DDL（如 CREATE TABLE），会导致后续 ROLLBACK 失效。
- 常规 INSERT/UPDATE/DELETE 不自动提交，可统一在循环外
COMMIT或ROLLBACK - 但若循环中调用了带
PRAGMA AUTONOMOUS_TRANSACTION的过程，每次调用都会独立提交，无法回滚——这种组合极易引发数据不一致 - 调试时可在循环内加
DBMS_OUTPUT.PUT_LINE('i='||i||', sql%rowcount='||SQL%ROWCOUNT);，确认 DML 是否真被执行，避免误以为“没效果”而盲目延长循环
真正麻烦的从来不是语法写不对，而是循环变量改了但逻辑没变、或者改了变量却绕过了关键分支——这类问题没法靠编译器报错发现，只能靠日志+断点+小数据集验证。
