SQL Server分批UPDATE应使用UPDATE TOP(n)加显式事务和ORDER BY，批次1000–5000，用@@ROWCOUNT终止循环，避免锁升级与重复漏更。
分批 COMMIT 不能降低锁级别，但能缩短锁持有时间、避免锁升级为表锁。 锁级别（行锁/页锁/表锁）由查询执行计划和数据访问模式决定，不是靠 COMMIT 频率控制的；真正起作用的是“每次只改少量行 + 立即释放锁”。
SQL Server 中用 UPDATE TOP(n) + 显式事务分批
这是最直接、兼容性最好、最容易落地的方式。不依赖主键连续性，也不需要提前查 ID 列表。
- 必须显式写
BEGIN TRANSACTION和COMMIT，不能依赖自动提交——否则每条UPDATE都是独立小事务，反而增加日志开销 -
UPDATE TOP(2000)后必须跟ORDER BY id，否则可能重复更新或漏更（无序时 SQL Server 不保证批次间不重叠） - 用
IF @@ROWCOUNT = 0 BREAK终止循环，而不是预估总行数——因为 WHERE 条件匹配的数据量会随更新动态减少 - 批次大小建议 1000～5000：小于 1000 会导致频繁提交拖慢整体速度；大于 5000 容易触发锁升级（SQL Server 默认 5000 行锁就尝试升为表锁）
WHILE (1=1)
BEGIN
UPDATE TOP(2000) orders
SET status = 'shipped'
WHERE status = 'pending'
ORDER BY id;
<pre class='brush:php;toolbar:false;'>IF @@ROWCOUNT = 0 BREAK;
COMMIT;
BEGIN TRANSACTION;END; COMMIT;
MySQL 中按主键范围分批（推荐用于有序主键）
适合主键递增、分布均匀的表。比 LIMIT 分页更稳定，避免因 DELETE 导致的空跳或重复扫描。
- 用
id BETWEEN @min_id AND @min_id + @batch_size - 1切片，每次只扫索引范围，不走全表 - 必须在每次循环后执行
COMMIT，否则锁不会释放；SET @min_id = @min_id + @batch_size才能推进 - WHERE 条件里不能对字段做函数操作，例如
WHERE DATE(create_time) = '2024-01-01'→ 会失效索引，导致全表扫描加锁 - 检查是否走索引：把 UPDATE 改成
EXPLAIN SELECT *，确认key列非NULL
为什么不能用 WHERE id IN (SELECT ...) 分批？
看着简洁，但实际风险高，尤其在 SQL Server 和高并发 MySQL 下：
- 子查询返回几万 ID 时，SQL Server 可能将结果缓存在 tempdb，同时对所有扫描过的行（哪怕没更新）加意向锁，大幅扩大锁范围
- 子查询若没
ORDER BY+TOP，优化器容易放弃索引走全表扫描，锁住整张表 - MySQL 的
IN列表受max_allowed_packet限制，超长会被截断，且无法感知影响行数是否为 0 来终止 - 更稳妥的做法是先
INSERT INTO @batch_ids SELECT TOP(n) id ...，再JOIN更新——把 ID 拿到内存中可控处理
最容易被忽略的一点：无论哪种方式，都要关掉 READ_COMMITTED_SNAPSHOT（如果开着）或者确认它没被误关——这个选项影响读操作是否加共享锁，但对写操作的排他锁无影响；真正关键的是让每次 UPDATE 扫描尽可能少的行，并立刻 COMMIT 释放 X 锁。
