sql server分批update必须配合有效索引、order by及合理批次大小，否则仍会全表扫描或锁升级；单次top不宜超5000行，需避免函数导致索引失效、无序引发重复/漏更，并通过waitfor delay缓解锁争用。

UPDATE 用 TOP 分批是基本操作，但光加 TOP 不够

直接写 UPDATE TOP (1000) ... 能限制单次影响行数，但若 WHERE 条件没走索引，SQL Server 仍可能扫描全表、持有大量页锁甚至表锁，其他查询照样被堵死。关键不在“分几批”，而在“每批扫多少”。

• 必须确保 WHERE 子句中的字段有有效索引（比如 status = 'active' 对应的 status 列建了非聚集索引）
• 避免在 WHERE 中用函数或表达式（如 WHERE YEAR(created_at) = 2025），否则索引失效，退化为扫描
• 如果更新条件涉及多个列，考虑创建覆盖索引，把 SET 的列也包含进去，减少书签查找带来的额外锁

为什么不能只靠事务包一层？

写 BEGIN TRAN; UPDATE TOP (1000) ...; COMMIT; 看似安全，但问题在于：事务提交前，所有被修改的行都持着排他锁（X 锁）。如果这批更新本身耗时长（比如触发了复杂计算、外键级联、触发器），锁就挂得久，别人还是等。

• 单次 TOP 批量不宜超过 5000 行，通常 500–2000 更稳妥，取决于平均行宽和 I/O 延迟
• 每批之间加短暂停（WAITFOR DELAY '00:00:00.05'），给其他事务喘息机会，避免连续抢锁
• 别在事务里做日志记录、发消息、调外部 API——这些都延长锁持有时间

WHERE 条件不唯一？小心跳过或重复更新

当用 TOP + WHERE 分批时，如果条件匹配的行没有确定排序，SQL Server 每次选的“前 1000 行”可能不一致，导致某些行被漏掉、某些行被反复更新。

• 必须搭配 ORDER BY（且该字段有索引），例如：UPDATE TOP (1000) t SET status = 'done' FROM jobs t WHERE status = 'pending' ORDER BY id
• 更稳的做法是用“游标式推进”：记录上一批最大 id，下一批从 WHERE id > @last_id AND status = 'pending' 开始
• 避免用 GETDATE() 或 NEWID() 这类非确定性函数参与排序或条件判断

READ COMMITTED SNAPSHOT 能缓解读写冲突，但不解决写写冲突

开了 RCSI 后，普通 SELECT 不再阻塞你的 UPDATE，反过来也一样。但两个并发的 UPDATE 语句仍会因争夺同一行的 X 锁而互相等待甚至死锁。

• RCSI 是基础配置，建议 OLTP 库默认开启，但它不是银弹
• 写写冲突还得靠业务层控制：比如对同一业务主键的更新，强制串行化（加应用锁或用队列），而不是依赖数据库扛并发
• 监控 sys.dm_exec_requests 中的 wait_type，如果是 LCK_M_U 或 LCK_M_X，说明就是更新锁争用，得回到 WHERE 和索引上查问题

分批 UPDATE 最容易被忽略的点，其实是“每批执行完是否真释放了锁”——不是 COMMIT 就万事大吉，得看执行计划里有没有意料之外的扫描、有没有隐式转换拖慢速度、有没有触发器悄悄拉长事务。上线前务必在相似数据量的预发环境跑一次真实压测。