能不用游标就别用——99%的逐行处理逻辑可用集合操作或可控批处理替代，性能提升10~1000倍；推荐优先使用update from、cte+row_number()分批、临时表+while循环等方案。
能不用游标就别用——99% 的存储过程里所谓“必须逐行处理”的逻辑，其实都能用集合操作或可控批处理替代，性能差10~1000倍不是夸张，是实测结果。
UPDATE FROM 一次性更新比游标快一个数量级
常见反模式是游标里循环执行 UPDATE t SET status = 'done' WHERE id = @id。每次 fetch 都触发一次主键查找、一次日志写入、一次锁申请，10万行就是10万次B-Tree定位。
- 直接改用
UPDATE ... FROM：用哈希连接一次完成全部匹配，锁只持有一个事务周期 - MySQL 不支持
UPDATE ... FROM，得写成UPDATE t JOIN s ON ... SET t.col = s.val - 如果更新依赖函数（如
dbo.calc_score(@id)），先物化到临时表再 JOIN，避免函数在 JOIN 条件里重复执行 - MERGE 在高并发下容易死锁，
UPDATE FROM更稳
CTE + ROW_NUMBER() 分批处理避免单行锁堆积
适用于需按顺序推进状态但又不能全量更新的场景，比如日志归档、分阶段审批、中间表填充。
- 用
ROW_NUMBER() OVER (ORDER BY created_time)打序号，ORDER BY字段必须有索引，否则会强制 SORT 消耗大量内存 - 别用
NEWID()排序——结果不可复现，且破坏索引利用 - 分片大小建议 5000~10000 行：太小导致循环次数多；太大易触发事务日志满（LOG FULL）
- 示例片段：
WITH numbered AS ( SELECT *, ROW_NUMBER() OVER (ORDER BY created_time) AS rn FROM orders WHERE status = 'pending' ) UPDATE o SET status = 'processed' FROM orders o INNER JOIN numbered n ON o.id = n.id WHERE n.rn BETWEEN @offset + 1 AND @offset + @batch_size;
临时表 + WHILE 循环比游标更轻量可控
仅当业务逻辑复杂到无法塞进一条 UPDATE 或 INSERT SELECT（比如要调外部存储过程、写审计日志、控制节奏）时才考虑。
- 先用
SELECT order_id, customer_id INTO #work_ids提取主键集，只查原表一次 - 用
MIN(order_id)或自增IDENTITY作驱动键，每次循环后必须推进：SET @current_id = (SELECT MIN(order_id) FROM #work_ids WHERE order_id > @current_id) - 循环体里用
WHERE order_id = @current_id精准定位，处理完立即DELETE FROM #work_ids WHERE order_id = @current_id防重 - 务必加
SET XACT_ABORT ON，否则某批失败可能导致后续批次卡住或数据不一致
真正难的不是选哪种替代方案，而是识别出哪些逻辑其实根本不需要“逐行”——比如滚动余额、移动平均，窗口函数 SUM() OVER (ORDER BY ...) 或 LAG() 就能搞定；组织架构遍历，WITH RECURSIVE 比游标清晰且可优化。游标不该是默认选项，而应是最后排查无解时的手动兜底。
