问题

在MySQL存储过程里使用游标进行循环操作时，原本运行正常的逻辑，在加入新功能后突然跳出循环，不再执行内部代码。这类问题很常见，根源往往与游标的done标志位状态异常有关。

解决

典型的游标声明和循环使用方式如下：

# 声明标志位，用来退出循环
declare done int default 0;
# 声明当游标中找不到数据时，设置done为1
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done=1;

游标的使用：

open cur;
posLoop:LOOP
  fetch cur into v_bjfh,v_yz,v_yjjb,v_dw;
  if done = 1 then lea ve posLoop;
  end if;
  -- 其他逻辑
end loop posLoop;
close cur;

问题在于：当执行到if done = 1时，循环直接退出，这表明done变量当前值为1，而非初始的0。理论上，CONTINUE HANDLER仅当游标无法获取数据时才将done设置为1，但循环刚启动，fetch尚未失败，done已被提前赋值。这通常是因为存储过程之前的执行逻辑意外修改了done变量，或者中断处理程序被过早触发。

解决方案很简单：在打开游标并进入循环之前，强制将done重置为0。

set done = 0;
open cur;
posLoop:LOOP
  fetch cur into v_bjfh,v_yz,v_yjjb,v_dw;
  if done = 1 then lea ve posLoop;
  end if;
  -- 其他逻辑
end loop posLoop;
close cur;

经过这样的修改，问题便能顺利解决。至于done变量之前是在何处被置为1，需要结合具体业务逻辑进行排查——可能是同一事务中其他语句触发了NOT FOUND条件，也可能是存储过程中其他游标的遗留副作用。

调试

MySQL不像Oracle那样支持断点调试功能，排查起来较为繁琐。常用的方法是直接在存储过程中使用select语句输出变量的当前值，例如：

select done;

通过输出变量的当前值，可以定位异常状态出现在何处。方法虽原始，但非常实用且高效。

总结

在MySQL存储过程的游标循环中，done标志位的状态管理是一个常见的易错点。养成进入循环前主动初始化done变量的习惯，可以有效避免“逻辑未变却跳出循环”的隐性故障。调试时善用select输出变量值，能够快速定位问题根源。