为什么在SQL中使用游标逐行更新极慢及如何改写为集合操作？-SQL-PHP中文网

游标比集合操作慢一个数量级，根本原因是其强制数据库退回到单线程过程式执行，导致上下文切换频繁、锁开销大、优化器失效；应优先用UPDATE+JOIN替代，复杂场景可分批集合处理。

为什么在sql中使用游标逐行更新极慢及如何改写为集合操作？

游标逐行更新极慢，根本原因不是语法写错了，而是它强行把数据库拉回单线程过程式执行模型——而SQL Server的优化器、索引、并行计划，全为集合操作设计。

游标为什么比集合操作慢一个数量级

每次 FETCH 都触发一次上下文切换和状态维护，相当于让数据库“停下批处理引擎，切到脚本模式”运行一次；同时游标默认开启事务锁，UPDATE 每行都可能独占页锁或行锁，10万行就是10万次加锁/释放；更关键的是，查询优化器对游标内部逻辑几乎无法生成有效执行计划，统计信息失效，索引也常被绕过。

常见错误现象包括：

执行时间随数据量线性增长（1万行 4 秒，10万行就 40 秒）
sp_who2 或 sys.dm_exec_requests 显示大量 WAIT_TYPE = LCK_M_U 或 LCK_M_S
执行计划里出现红色警告：“No Join Predicate”或“Table Scan”出现在原应走索引的位置

直接替换：用 UPDATE + JOIN 替代游标更新

绝大多数游标更新场景，其实只需要一条带关联的 UPDATE 就能等价替代。核心是把“先查 ID，再按 ID 更新”合并成一步。

例如这个典型游标写法：

DECLARE @ID INT;
DECLARE cur CURSOR FOR SELECT ID FROM Orders WHERE Status = 'pending';
OPEN cur;
FETCH NEXT FROM cur INTO @ID;
WHILE @@FETCH_STATUS = 0
BEGIN
  UPDATE OrderItems SET Processed = 1 WHERE OrderID = @ID;
  FETCH NEXT FROM cur INTO @ID;
END
CLOSE cur; DEALLOCATE cur;

应改写为：

UPDATE oi
SET Processed = 1
FROM OrderItems oi
INNER JOIN Orders o ON oi.OrderID = o.ID
WHERE o.Status = 'pending';

注意点：

必须显式使用表别名（如 oi），否则 SQL Server 不允许在 UPDATE 中用 FROM 关联多表
确保 Orders.ID 和 OrderItems.OrderID 上有索引，否则 JOIN 会退化为嵌套循环+全表扫描
如果 Orders 表过滤条件选择性差（比如 Status 只有 3 个值），考虑加覆盖索引：CREATE INDEX IX_Orders_Status_ID ON Orders(Status) INCLUDE(ID);

复杂逻辑无法单条 UPDATE 完成？用临时表分批 + 集合操作

当业务逻辑涉及多个判断分支、调用函数、或需读取多张中间表时，硬塞进一条 UPDATE 会变得难读难调。这时不要退回游标，改用“提取主键 → 分批处理 → 每批集合更新”的折中方案。

示例步骤：

先用 SELECT ID INTO #work_ids FROM Orders WHERE ... 把待处理主键一次性取出，避免后续重复扫描
用 WHILE 控制批次（如每次 5000 行），但每批内仍用 UPDATE ... WHERE ID IN (SELECT TOP 5000 ID FROM #work_ids) 或 JOIN 方式批量更新
每批后 DELETE TOP (5000) FROM #work_ids，防止漏处理；不建议用 OFFSET/FETCH，因并发下可能跳行
关键：所有需要的字段（非仅 ID）应在第一步 SELECT INTO 时一并带上，避免循环中反复查源表