MySQL存储过程不支持FOR循环，需用WHILE或LOOP实现批处理，但应优先用单条SQL替代循环以提升性能；WHILE需手动维护计数器，游标遍历须配NOT FOUND HANDLER与LEAVE，标签命名须准确且唯一，变量作用域限于当前过程。
MySQL存储过程中没有FOR循环语法，但能用WHILE或LOOP实现批处理——关键不是“怎么写循环”，而是“怎么避免把批量逻辑写成伪循环”。
WHILE循环必须配变量+显式递增
MySQL的WHILE不自动管理计数器，漏掉SET counter = counter + 1就会死循环。常见错误是把条件写成WHILE counter ，却在循环体里忘了更新<code>counter。
- 必须用
DECLARE声明局部变量，且DEFAULT值要明确（如DECLARE i INT DEFAULT 1） - 每次迭代后必须手动更新变量，不能依赖隐式行为
- 退出条件建议用
LEAVE配合IF判断，比单纯靠WHILE条件更可控 - 示例中
adjustment_loop: WHILE current_avg 后面紧跟着<code>IF loop_count >= max_loop THEN LEAVE adjustment_loop;，就是防兜底
游标遍历结果集时，LEAVE必须和NOT FOUND HANDLER配对
用游标逐行处理查询结果时，FETCH读不到数据不会报错，而是让变量保持旧值或NULL——这时候仅靠IF var IS NULL判断不可靠，容易多执行一次。
- 必须声明
DECLARE done INT DEFAULT FALSE并绑定CONTINUE HANDLER FOR NOT FOUND SET done = TRUE -
LEAVE只能跳出最内层标记的循环（如read_loop: LOOP ... LEAVE read_loop），不能跨层跳 - 游标打开后必须
CLOSE，否则下次调用会报Cursor is already open - 不要在循环体内反复
SELECT ... INTO查同一张表，性能极差；应提前把中间结果存入临时表
真正高效的“批处理”往往不需要循环
90%以上场景下，用单条UPDATE/INSERT ... SELECT替代循环，性能提升一个数量级。循环只是“兜底方案”，不是首选。
- 比如按条件批量更新状态：
UPDATE users SET status = 1 WHERE status = 0，比游标+逐行UPDATE快几十倍 - 需要关联计算？先
INSERT INTO temp_table SELECT ... JOIN ...，再用UPDATE main JOIN temp_table一次性刷入 - 循环只在必须“动态决策下一步操作”时才必要，例如：每轮调整后要重新算平均薪资再决定是否继续
- 如果循环里有
COMMIT，记得外面包START TRANSACTION，否则会报Transaction isolation level can't be changed while a transaction is in progress
LOOP标签命名和嵌套容易出错
LOOP语句本身无条件，全靠LEAVE label跳出，标签名拼错、漏写或嵌套时混淆层级，会导致跳转失败或跳过不该跳的代码段。
- 标签名必须和
LEAVE后的一致，大小写敏感（my_loop: LOOP→LEAVE my_loop） - 嵌套循环时，外层标签必须唯一，且
LEAVE只能跳出同名最近的那层 - 别省略标签名——
LOOP ... END LOOP没标签，LEAVE就无效，直接报错 - 调试时可在循环体开头加
SELECT CONCAT('loop #', i);，但上线前务必删掉，否则影响性能
最常被忽略的一点：循环变量作用域只在存储过程内，不能跨CALL保留；而事务边界默认是整个存储过程，除非显式COMMIT或ROLLBACK——这两点一旦搞混，重试逻辑或分批提交就会失效。
