游标比集合操作慢一个数量级，根本原因是其强制数据库退回到单线程过程式执行，导致上下文切换频繁、锁开销大、优化器失效；应优先用UPDATE+JOIN替代，复杂场景可分批集合处理。
游标逐行更新极慢，根本原因不是语法写错了，而是它强行把数据库拉回单线程过程式执行模型——而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时一并带上，避免循环中反复查源表
真正容易被忽略的点是：游标慢不慢，不取决于你写了多少行代码，而取决于你有没有让数据库“做它最擅长的事”。哪怕只改一行 SQL，只要把 FETCH + UPDATE 换成 UPDATE ... FROM ... JOIN，性能差距就可能是 10 倍起跳——因为你在释放优化器，而不是绕过它。
