绝大多数“遍历后更新”场景可用UPDATE+JOIN替代游标，如多表关联更新、分批处理（CTE+ROW_NUMBER）或临时表+WHILE，仅极少数需调用外部API、树形递归等无法集合化的场景才用游标。
用 UPDATE + JOIN 一次性替代游标逐行更新
绝大多数“遍历后更新”的场景，根本不需要游标。比如把 orders 表中所有 status = 'pending' 的记录设为 'processed'，直接写 UPDATE orders SET status = 'processed' WHERE status = 'pending' 就完事——连子查询都不用。
如果更新逻辑依赖另一张表（例如根据 customers 的等级决定订单状态），就用 JOIN：
UPDATE o SET o.status = 'vip_processed' FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE c.tier = 'VIP' AND o.status = 'pending';
常见错误是把 JOIN 写成子查询 + IN，尤其当子查询返回 NULL 时，IN (..., NULL) 整个条件失效；而 JOIN 天然过滤 NULL 关联。
注意点：
- 确保
JOIN条件字段有索引，否则执行计划可能退化为嵌套循环+全表扫描 - 避免在
WHERE中对字段用函数，如WHERE YEAR(created_at) = 2025，会跳过索引 - SQL Server 中，
MERGE语句适合“存在则更新、不存在则插入”混合逻辑，但需显式加WITH (HOLDLOCK)防止并发冲突
用 CTE + ROW_NUMBER() 分批处理大结果集
当业务逻辑无法压缩进单条 UPDATE（比如要调用函数、写日志、或触发外部检查），又必须顺序处理且数据量上万，就别用游标，改用窗口函数分片。
核心是把“逐行 fetch”变成“按块 update”，靠 ROW_NUMBER() OVER (ORDER BY ...) 打序号，再用 WHERE rn BETWEEN @start AND @end 控制批次：
WITH numbered AS ( SELECT id, order_no, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM orders WHERE status = 'pending' ) UPDATE o SET status = 'processing' FROM orders o INNER JOIN numbered n ON o.id = n.id WHERE n.rn BETWEEN @offset + 1 AND @offset + 5000;
关键细节：
-
ORDER BY字段必须有索引，否则ROW_NUMBER()强制排序，内存暴涨 - 批次大小设 5000–10000 行：太小导致循环次数多；太大易填满事务日志
- 别用
NEWID()或GETDATE()做排序依据，它们不可复现、无法走索引 - 每次执行后更新
@offset，用@@ROWCOUNT判断是否还有剩余
用临时表 + WHILE 模拟可控批处理
当每行处理逻辑极其复杂（比如要查 3 张表、拼 JSON、发 HTTP 请求），连分片 UPDATE 都写不出来，就用临时表存主键，再用 WHILE 取一批 ID 处理——这比游标轻量得多，且能控制事务边界。
先一次性把要处理的 ID 和必要字段塞进临时表：
SELECT id, customer_id, amount INTO #work_orders FROM orders WHERE status = 'pending' ORDER BY id;
然后循环取批：
WHILE EXISTS (SELECT 1 FROM #work_orders)
BEGIN
BEGIN TRY
BEGIN TRANSACTION;
<pre class="brush:php;toolbar:false;">-- 取出最多 100 行，同时删掉它们（防重处理）
DELETE TOP (100)
FROM #work_orders
OUTPUT DELETED.id, DELETED.customer_id, DELETED.amount
INTO #batch;
-- 在 #batch 上做复杂逻辑（可 JOIN、调函数、INSERT 日志等）
INSERT INTO processing_log (...) SELECT ... FROM #batch;
COMMIT TRANSACTION;END TRY BEGIN CATCH ROLLBACK TRANSACTION; THROW; -- 别吞异常 END CATCH END
容易踩的坑：
- 临时表名用
#work_orders这种明确前缀，别用#temp这类泛称，防命名冲突 - 务必用
DELETE TOP+OUTPUT，而不是SELECT TOP+DELETE WHERE id IN (...)，后者在并发下可能漏删或重复删 - 每批独立事务，失败不影响后续批次；但得加
SET XACT_ABORT ON，否则某批死锁可能卡住整个循环 - 临时表里只放真正需要的字段，别
SELECT *，减少 TempDB 压力
什么情况真没法绕开游标？
极少数场景下，集合操作确实无解，比如：
- 逐行调用
sp_send_dbmail发不同内容的邮件，且每封邮件需带唯一附件（SQL Server 不支持批量发带附件邮件） - 处理树形结构时，父节点处理结果直接影响子节点参数，且深度不确定（这时递归 CTE 也难覆盖）
- 对接老旧系统，要求按严格顺序调用外部 Web API，且 API 限流、需错峰
如果真落到这种地步，至少做到三点：
- 用
DECLARE my_cursor CURSOR FAST_FORWARD READ_ONLY，禁掉动态性，减少锁和内存开销 - 游标查询本身必须走覆盖索引，
SELECT字段全在索引INCLUDE里，避免键查找 - 在循环体里别再查原表——所有依赖数据，都在游标声明时
SELECT进来
最后提醒一句：只要看到 DECLARE CURSOR，第一反应不该是“怎么写得更顺”，而是“这个需求能不能拆成两步？第一步集合生成中间表，第二步用临时表驱动？”——多数时候，答案都是能。
