如何在MySQL存储过程中使用游标循环遍历_声明打开与关闭游标步骤
说起来，MySQL存储过程中的游标使用，有一套非常严格的“规矩”。简单概括就是：游标声明必须在变量和条件声明之后、HANDLER之前，并且整个流程必须严格遵循OPEN-FETCH-CLOSE的步骤。循环退出得依赖NOT FOUND句柄来控制，想用COUNT预判行数或者在循环里修改源表？这些操作可都是行不通的。
MySQL存储过程中声明游标必须在DECLARE中靠前位置
MySQL对声明顺序的要求近乎苛刻。游标声明（DECLARE cursor_name CURSOR FOR ...）必须放在所有变量和条件声明之后，但又必须在OPEN语句之前。一个常见的坑是，把游标声明写在了DECLARE CONTINUE HANDLER之后，或者夹在变量赋值语句中间，这都会直接导致 ERROR 1337 (42000): Variable or condition declaration after cursor or handler declaration 错误。
正确的顺序应该是这样的：
DECLARE var_name INT DEFAULT 0; DECLARE done INT DEFAULT FALSE; -- 用于控制循环的标志 DECLARE cur CURSOR FOR SELECT id, name FROM users WHERE status = 1; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
这里有几个关键点需要注意：用于控制循环的 done 变量，必须在游标和句柄之间声明。而 CONTINUE HANDLER 必须紧跟在游标声明之后，并且它只能捕获 NOT FOUND 条件（对应 SQLSTATE '02000'）。想用 SQLWARNING 或 SQLEXCEPTION 来替代？这会导致循环无法可靠退出，千万别这么干。
OPEN/FETCH/CLOSE三步缺一不可，FETCH必须紧跟OPEN后首次调用
游标可不是声明完就能自动工作的。必须显式地执行 OPEN 操作，才能开始读取数据。每次 FETCH 只会取出一行，并移动内部的指针。循环结束后，必须记得 CLOSE，否则可能会长期占用连接资源，尤其是在长事务或高并发场景下，这可是个隐形杀手。
一个典型的使用结构如下：
OPEN cur;
read_loop: LOOP
FETCH cur INTO @id, @name;
IF done THEN
LEA VE read_loop;
END IF;
-- 处理当前行：比如 INSERT/UPDATE/计算等
END LOOP;
CLOSE cur;
这里面藏着几个魔鬼细节：
FETCH必须在OPEN之后立即执行一次。如果不这么做，done标志就不会被触发，循环可能会因为初始值done = FALSE而无限执行下去。FETCH ... INTO后面跟的变量类型，必须与查询字段的类型严格匹配。否则，隐式转换失败时可能不会报错，但取出来的值可能是NULL或被截断的，导致后续逻辑出错。- 记住，不要在循环内部重复
OPEN同一个游标。MySQL不支持重新打开一个已经关闭的游标，这么做会直接抛出ERROR 1326 (HY000): Cursor is not open。
循环退出依赖NOT FOUND句柄，不能靠SELECT COUNT()预判行数
MySQL的游标没有提供像 ROWCOUNT 或 ISOPEN 这样的状态函数。因此，唯一可靠的循环结束方式，就是依赖 NOT FOUND 条件触发句柄，将 done 标志设为 TRUE。有些开发者想走捷径，试图先用 SELECT COUNT(*) 查出总数，再用 WHILE i <= cnt 来控制循环。这不仅是多了一次查询开销那么简单，更严重的是，在并发写入的场景下，你预先查出的计数很可能和实际游标遍历时的结果集对不上，导致逻辑错误。
还有一些更隐蔽的陷阱：
- 如果游标查询本身就没有结果（比如
WHERE条件一个都不匹配），那么OPEN之后第一次FETCH就会立刻触发NOT FOUND，done标志马上变成TRUE，循环体一次都不会执行——这是预期内的正常行为，可不是什么bug。 - 如果在循环体内执行了修改游标源表的操作（比如
DELETE当前行），那么后续的FETCH行为将是未定义的，可能会跳过某些行，也可能重复取值，应当极力避免这种情况。 CONTINUE HANDLER是作用域敏感的。它只对同一代码块内的语句生效。如果把游标逻辑包裹在嵌套的BEGIN...END块中，那么这个句柄也必须在同一个块内部声明。
性能差是常态，单次处理多行比游标更现实
必须正视一个现实：MySQL游标的本质是在数据库层逐行模拟应用层的迭代，它无法利用批量操作的优化，执行效率远低于等价的集合操作。举个例子，要给所有活跃用户发通知，如果用游标一条条调用 INSERT INTO logs，其速度会比直接使用 INSERT INTO logs SELECT ... FROM users WHERE status = 1 这样的集合操作慢上一个数量级，而且锁持有的时间也更长。
那么，什么时候才应该考虑使用游标呢？通常只有当以下条件全部满足时：
- 业务逻辑强依赖于上一行的处理结果（例如复杂的累计求和、状态机流转）。
- 需要在循环中调用无法向量化的过程（比如调用一个内部包含独立事务控制的子过程）。
- 数据量极小（通常小于100行），并且无法通过重构为临时表加JOIN的方式来实现。
还有一个真正容易被忽略的痛点：游标在存储过程中调试起来非常困难。你无法直接用 SELECT 查看游标当前的内容，SHOW PROCESSLIST 也看不到游标的状态。通常只能通过 SELECT 输出临时变量，或者写入日志表来追踪执行过程。一旦逻辑出错，定位问题比调试纯SQL语句要耗时得多。所以说，游标虽有其用武之地，但务必谨慎使用，三思而后行。
