如何在MySQL存储过程中遍历查询结果

MySQL存储过程需用游标遍历结果集，必须声明在DECLARE块中、定义NOT FOUND CONTINUE HANDLER、OPEN后配合REPEAT/WHILE循环FETCH，并立即检查done标志防重复处理；临时表方案虽可行但性能差且不适用于大数据或并发场景。

MySQL存储过程里怎么用游标遍历查询结果

MySQL不支持像Python或Java那样的for循环直接遍历结果集，必须用游标（CURSOR）配合FETCH手动取值。这是最常用也最稳妥的方式，但容易因声明顺序、异常处理不到位导致过程卡死或跳过数据。

关键约束：游标只能在存储过程或函数内声明，且必须在DECLARE语句块中——放在变量声明之后、异常处理器之前；游标打开前，对应SELECT语句不能含动态SQL或参数化表名。

1. DECLARE游标时，SELECT语句必须是静态的，不能拼接表名或列名
2. 必须定义NOT FOUND处理器，否则FETCH到末尾会报错中断过程
3. 游标打开后，每次FETCH只取一行，需搭配REPEAT或WHILE循环使用

DECLARE cur_name CURSOR FOR SELECT id, name FROM users WHERE status = 1;DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;OPEN cur_name;REPEATFETCH cur_name INTO v_id, v_name;IF NOT done THEN-- 处理单行逻辑，比如 INSERT INTO log_table VALUES (v_id, v_name);END IF;UNTIL done END REPEAT;CLOSE cur_name;

为什么FETCH后要立刻检查done标志

MySQL的FETCH本身不返回布尔值，也不抛出“无数据”异常——它只是把当前行字段值赋给变量，到末尾时静默停止赋值，变量保持上一次的值。如果不立即用IF NOT done判断，就会重复处理最后一行，甚至无限循环。

常见错误现象：done变量未初始化为FALSE，或处理器写成EXIT HANDLER（会导致整个过程退出，而非跳出循环）。

1. SET done = FALSE必须在OPEN之前显式执行
2. 处理器必须是CONTINUE HANDLER，不是EXIT
3. FETCH后立刻判断done，不能放到循环体末尾再判

替代方案：用临时表+WHILE循环能绕开游标吗

可以，但不推荐用于大数据量。原理是把查询结果插入TEMPORARY TABLE，再用SELECT COUNT(*)和自增ID模拟遍历。好处是逻辑直白、易调试；坏处是临时表IO开销大，且无法应对并发修改原表的场景。

适用场景：结果集固定且小于1000行，且不需要实时反映源表变更。

1. 临时表必须显式DROP TEMPORARY TABLE，否则可能残留影响后续调用
2. WHILE循环里每次SELECT ... LIMIT 1 OFFSET n性能随偏移量增大急剧下降
3. 不如游标稳定，尤其在事务中嵌套调用时，临时表可见性容易出问题

存储过程中遍历结果时最容易漏掉的兼容性细节

MySQL 5.7默认开启sql_mode=STRICT_TRANS_TABLES，如果游标SELECT里的字段类型和INTO变量不严格匹配（比如VARCHAR(50)接收了超长值），会直接报错中断，而不是截断。这点和8.0+的宽松模式不同。

另一个坑是字符集：若连接层用utf8mb4，但存储过程内部变量声明为CHAR未指定字符集，可能隐式转码失败。

1. 所有INTO变量类型应与查询字段完全一致，宁可用TEXT代替VARCHAR避免截断
2. 显式声明变量字符集，如DECLARE v_name VARCHAR(100) CHARACTER SET utf8mb4
3. 测试时务必在目标MySQL版本下执行，5.7和8.0对游标DECLARE位置的语法容忍度不同

游标不是黑盒，它的行为高度依赖声明顺序、错误处理粒度和变量生命周期。写完别急着上线，用SELECT查一遍游标源SQL结果，再单步走一遍FETCH逻辑，比加日志更早发现问题。