在进行数据库操作时，建议优先考虑使用UPDATE FROM或JOIN来进行批量更新，以此替代游标操作。

原因很直接：游标逐行更新时，处理10万行数据，需要进行10万次的B-Tree查找、加锁以及日志刷盘操作；而采用集合操作，通过一次哈希连接就能完成相同任务。

对于MySQL数据库，需要将语法调整为UPDATE JOIN。如果遇到复杂逻辑，可以先将数据物化到#updates表中。需要注意的是，MERGE操作在高并发情况下容易出现死锁问题，相比之下，UPDATE FROM的稳定性更高。

UPDATE FROM 一次性更新替代游标逐行 UPDATE

游标里写 UPDATE t SET status = 'done' WHERE id = @id，本质上是让数据库为每一行重复做主键查找、加锁、写日志。

10万行就是10万次B-Tree定位 + 10万次事务日志刷盘。

更合适的方式，是直接改用集合操作：

UPDATE o 
SET status = 'processed' 
FROM orders o 
INNER JOIN #updates u ON o.id = u.order_id;

• #updates 必须提前物化好（SELECT id INTO #updates FROM ...），别在 JOIN 里嵌套子查询或函数调用
• MySQL 不支持 UPDATE ... FROM，得写成 UPDATE t JOIN s ON ... SET t.col = s.val
• MERGE 虽然语义清晰，但在高并发下容易死锁，UPDATE FROM 更稳
• 如果更新逻辑依赖计算（比如 dbo.calc_score(@id)），先算好存进 #updates，别让它在 JOIN 中反复执行

CTE + ROW_NUMBER() 分批处理替代顺序游标

这种方式适合必须按时间或ID顺序推进、又不能全量更新的场景。

例如：分阶段状态流转、日志归档。

WITH batch AS (
SELECT id, created_time,
 ROW_NUMBER() OVER (ORDER BY created_time) AS rn
FROM orders 
WHERE status = 'pending'
)
SELECT * FROM batch WHERE rn BETWEEN @start AND @end;

• ORDER BY 字段必须有索引，否则 ROW_NUMBER() 会强制排序，内存暴涨甚至溢出到tempdb
• 别用 NEWID() 排序——破坏索引利用，结果不可复现，批次不一致
• 分片大小建议 5000–10000 行：小于 5000 循环次数多；大于 10000 容易触发 LOG FULL 或锁升级成表锁

WHILE + 临时表模拟可控逐行处理

只有当业务逻辑无法塞进单条SQL时才使用这种方式。

比如要调外部存储过程、写审计日志、控制每秒处理数，或依赖上一行结果。

SELECT id INTO #work_ids FROM orders WHERE status = 'pending';
SET XACT_ABORT ON;
WHILE EXISTS (SELECT 1 FROM #work_ids) BEGIN
DECLARE @id INT = (SELECT TOP 1 id FROM #work_ids);
-- 处理单行逻辑
EXEC do_something @id;
DELETE FROM #work_ids WHERE id = @id;
END

• 第一步只查一次原表，把主键集提取进 #work_ids，避免每次循环都扫描原表
• 用 TOP 1 或 MIN(id) 驱动，别用游标式 FETCH NEXT
• 每次处理完立刻 DELETE 对应行，防止重跑或漏跑
• SET XACT_ABORT ON 是硬性要求，否则某次失败会导致后续循环卡住或数据残留

真正难的是判断“该不该逐行”

很多人不是不会写 WHILE，而是没想清楚：当前逻辑是否真的需要逐行？有没有隐藏的集合表达可能？

比如状态机推进看似要顺序处理，但有时用 CASE WHEN + 窗口函数，就能一次算出终态。

游标不是语法错误，而是设计信号。它提示你：这段逻辑可能没被数据库引擎友好接纳。

《夸克》非常好用的免费AI浏览器

下载APP查看