SQL存储过程游标循环更新符合条件的记录

先说一个基本判断：游标在大多数业务场景下都不是最优解，但有些时候你确实绕不开它。比如你需要逐行处理结果集——根据某字段的值动态计算并更新另一个字段，而这类逻辑用一条 UPDATE ... JOIN 或窗口函数搞不定的时候，游标才真正派上用场。

SQL Server 里声明显式游标的标准写法是这样的：DECLARE 游标名 CURSOR [LOCAL | GLOBAL] [FORWARD_ONLY | SCROLL] [STATIC | KEYSET | DYNAMIC | FAST_FORWARD] FOR SELECT语句。声明之后，还得配合 OPEN、FETCH NEXT INTO、WHILE @@FETCH_STATUS=0 循环、CLOSE 和 DEALLOCATE 一套流程走完。

SQL Server 游标声明规范与常见错误

实际操作中几个容易踩的坑：首先，不要忘了 DEALLOCATE——漏掉它的后果就是下次执行时报错“The cursor is already declared”。其次，循环里如果忘记用 FETCH NEXT 更新对应的 @variable，程序就陷入无限循环了。

给出几条实操建议：

• 声明游标时，始终加上 LOCAL FAST_FORWARD——只读、前向、轻量，性能更好：
  

  DECLARE cur_update CURSOR LOCAL FAST_FORWARD FOR SELECT id, amount FROM orders WHERE status = 'pending'

• 变量类型必须和查询列严格匹配。比如 id 是 INT，就别声明成 @id VARCHAR(10)。
• FETCH 之后立即检查 @@FETCH_STATUS = 0，否则可能处理到空行或上一轮残留的值。

游标循环内的 UPDATE 语句必须使用主键定位

这里有个容易混淆的地方：游标本身不提供更新能力，你得自己在循环里写 UPDATE 语句。重点来了——这条 UPDATE 必须用主键或唯一约束精确锁定记录。如果写成 UPDATE orders SET ... WHERE status = 'pending'，每次循环都会扫描整个表里所有符合条件的行，这不是“更新当前行”，而是在反复更新整个结果集。

典型的场景是：对每个待处理的订单，按实时汇率换算 amount_usd 字段。

操作要点：

• SELECT 子句中一定要包含用于定位的主键（比如 id），并且在 UPDATE 的 WHERE 里用上它：
  

  UPDATE orders SET amount_usd = @amount * @exchange_rate WHERE id = @id

• 避免在循环内部再查表（比如再去 SELECT 用户信息），提前把需要的关联字段一并 SELECT 出来。
• 如果业务允许，优先考虑 CTE + UPDATE ... FROM 替代游标，性能通常高一个数量级。

MySQL 存储过程游标处理：使用 NOT FOUND 替代 FETCH STATUS

MySQL 和 SQL Server 在游标处理上有个关键区别：MySQL 不支持 @@FETCH_STATUS。你必须用 DECLARE CONTINUE HANDLER FOR NOT FOUND 来捕获游标耗尽的信号。如果漏掉 handler，循环执行一次就直接退出了——只处理了第一行记录。

遇到这种问题时的典型表现：存储过程执行完，只更新了第一条记录，而且控制台没有任何报错提示。

建议的做法：

• handler 必须在 OPEN 之前声明，同时需要在 handler 内给标记变量（比如 @done）赋值：
  

  DECLARE done INT DEFAULT FALSE;
  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

• FETCH 之后立即检查 done 的状态，不要等到下次循环开始再判断：
  

  FETCH cur INTO @id, @amount;
  IF done THEN LEAVE read_loop; END IF;

• MySQL 的游标不可滚动、不可更新、只能读取，UPDATE 必须单独写语句。

游标性能优化：哪些场景其实可以避免使用游标

从实际经验来看，90%所谓“必须用游标”的需求，本质上是没想清楚数据操作是否可以用集合方式解决。打个比方，要“给每个用户发通知”——正确的做法不是用游标逐个去查用户再调存储过程发邮件，而是生成一张通知记录表，让后台任务异步去消费。

几个容易被忽略的思路：

• UPDATE ... FROM（SQL Server）或 UPDATE ... JOIN（MySQL）能解决大部分“查-算-改”的链路。
• 临时表 + WHILE 循环（SQL Server）比游标快，省去了游标自身的开销，而且可以加索引。
• 触发器或者应用层的分页处理，有时比数据库层的游标更可控、更容易监控。
• 如果游标循环里还嵌套了远程查询、文件 I/O 或 HTTP 调用——坦白说，这已经超出数据库的职责范围了，应该考虑移出存储过程。