MySQL存储过程需用游标遍历结果集，必须声明在DECLARE块中、定义NOT FOUND CONTINUE HANDLER、OPEN后配合REPEAT/WHILE循环FETCH，并立即检查done标志防重复处理；临时表方案虽可行但性能差且不适用于大数据或并发场景。
MySQL存储过程里怎么用游标遍历查询结果
MySQL不支持像Python或Java那样的for循环直接遍历结果集，必须用游标（CURSOR）配合FETCH手动取值。这是最常用也最稳妥的方式，但容易因声明顺序、异常处理不到位导致过程卡死或跳过数据。
关键约束：游标只能在存储过程或函数内声明，且必须在DECLARE语句块中——放在变量声明之后、异常处理器之前；游标打开前，对应SELECT语句不能含动态SQL或参数化表名。
-
DECLARE游标时，SELECT语句必须是静态的，不能拼接表名或列名 - 必须定义
NOT FOUND处理器，否则FETCH到末尾会报错中断过程 - 游标打开后，每次
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;
REPEAT
FETCH 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（会导致整个过程退出，而非跳出循环）。
-
SET done = FALSE必须在OPEN之前显式执行 - 处理器必须是
CONTINUE HANDLER，不是EXIT -
FETCH后立刻判断done，不能放到循环体末尾再判
替代方案：用临时表+WHILE循环能绕开游标吗
可以，但不推荐用于大数据量。原理是把查询结果插入TEMPORARY TABLE，再用SELECT COUNT(*)和自增ID模拟遍历。好处是逻辑直白、易调试；坏处是临时表IO开销大，且无法应对并发修改原表的场景。
适用场景：结果集固定且小于1000行，且不需要实时反映源表变更。
- 临时表必须显式
DROP TEMPORARY TABLE，否则可能残留影响后续调用 -
WHILE循环里每次SELECT ... LIMIT 1 OFFSET n性能随偏移量增大急剧下降 - 不如游标稳定，尤其在事务中嵌套调用时，临时表可见性容易出问题
存储过程中遍历结果时最容易漏掉的兼容性细节
MySQL 5.7默认开启sql_mode=STRICT_TRANS_TABLES，如果游标SELECT里的字段类型和INTO变量不严格匹配（比如VARCHAR(50)接收了超长值），会直接报错中断，而不是截断。这点和8.0+的宽松模式不同。
另一个坑是字符集：若连接层用utf8mb4，但存储过程内部变量声明为CHAR未指定字符集，可能隐式转码失败。
- 所有
INTO变量类型应与查询字段完全一致，宁可用TEXT代替VARCHAR避免截断 - 显式声明变量字符集，如
DECLARE v_name VARCHAR(100) CHARACTER SET utf8mb4 - 测试时务必在目标MySQL版本下执行，5.7和8.0对游标
DECLARE位置的语法容忍度不同
游标不是黑盒，它的行为高度依赖声明顺序、错误处理粒度和变量生命周期。写完别急着上线，用SELECT查一遍游标源SQL结果，再单步走一遍FETCH逻辑，比加日志更早发现问题。
