必须拆分批量更新为可控批次，因in子查询易致锁表、oom或超时；推荐用表变量+join分批或update top(n)循环，且目标列需有索引。
直接用 WHERE id IN (SELECT ...) 更新几十万行，大概率锁表、OOM 或超时。必须拆成可控批次，核心是绕过子查询的不可控性。
为什么不能让子查询直接进 UPDATE 的 WHERE 条件
SQL Server 对 UPDATE ... WHERE id IN (SELECT ...) 的执行计划很敏感：
- 子查询若没
ORDER BY+TOP(n)，优化器可能放弃索引，走全表扫描 - 即使子查询只返回 10 万 ID，SQL Server 也可能对整个扫描范围加意向锁，最终触发锁升级为表锁
- 子查询结果若含函数（如
CONVERT(VARCHAR, created_at)）、JOIN 或聚合，基本无法命中索引 -
IN子句本身不控制单次影响行数，你没法插WAITFOR DELAY缓冲 I/O 压力
用表变量 + JOIN 分批更新（推荐）
这是最稳妥、可预测、易调试的方式，适用于所有 SQL Server 2005+ 版本：
- 先用
INSERT INTO @batch_ids SELECT TOP(2000) id FROM ... ORDER BY id抽出一批 ID - 再用
UPDATE o SET ... FROM orders o INNER JOIN @batch_ids b ON o.id = b.id精准更新这批 - 每次循环后
DELETE FROM @batch_ids清空，避免重复处理 - 循环条件用
WHILE EXISTS (SELECT 1 FROM @batch_ids)，比硬算总行数更可靠——因为 WHERE 条件可能随更新动态变化
DECLARE @batch_ids TABLE (id INT PRIMARY KEY);
INSERT INTO @batch_ids
SELECT TOP(2000) id
FROM orders
WHERE status = 'pending'
ORDER BY id;
WHILE EXISTS (SELECT 1 FROM @batch_ids)
BEGIN
UPDATE o
SET o.status = 'shipped'
FROM orders o
INNER JOIN @batch_ids b ON o.id = b.id;
DELETE FROM @batch_ids;
INSERT INTO @batch_ids
SELECT TOP(2000) id
FROM orders
WHERE status = 'pending'
ORDER BY id;
END;
UPDATE TOP(n) 循环（最快落地，但有约束）
如果表有合适排序字段（如自增 id），且能接受“每次只改固定行数”，这个方案最简、性能最好：
- 必须显式
BEGIN TRANSACTION+COMMIT，否则默认自动提交会让每条UPDATE都开销翻倍 -
UPDATE TOP(2000)后必须跟ORDER BY id，否则同一批可能重复更新或漏更 - 批次大小建议 1000–5000：太小（如 100）导致事务频繁提交拖慢整体；太大（如 50000）易触发锁升级
- 终止条件只能用
IF @@ROWCOUNT = 0 BREAK，不能靠计数器——因为WHERE status = 'pending'这个条件在更新过程中会动态减少匹配行
BEGIN TRANSACTION;
WHILE (1=1)
BEGIN
UPDATE TOP(2000) orders
SET status = 'shipped'
WHERE status = 'pending'
ORDER BY id;
IF @@ROWCOUNT = 0 BREAK;
COMMIT;
BEGIN TRANSACTION;
END;
COMMIT;
真正容易被忽略的点是：无论选哪种方式，都要确认目标列（比如 status）上有索引。否则 WHERE status = 'pending' 每次都全表扫，分批就失去意义。
