运行大规模批量更新脚本时遇锁请求超时（Msg 1222）求助

嘿，我太懂你现在的糟心了——5000万条记录的批量更新，分了批次还两次中途挂掉，锁超时确实够闹心的。咱们一步步拆解问题，给你几个实际能用的解决办法：

1. 把批次拆得更细碎，缩小锁范围 #

你已经做了批次拆分，但看起来当前的批次大小还是让数据库锁了太多资源，导致超时。试试把每批次的更新量从可能的几万条砍到1000-5000条（具体数值可以根据你的服务器性能微调）。更小的批次意味着每次事务持锁的时间更短，锁的范围也更小，不容易和其他进程冲突。

比如把你的批次逻辑改成这样：

DECLARE @BatchSize INT = 2000;
DECLARE @RowCount INT = 1;

WHILE @RowCount > 0
BEGIN
    BEGIN TRANSACTION;

    UPDATE TOP(@BatchSize) YourTable
    SET ColumnToUpdate = NewValue
    WHERE UpdateCondition = SomeValue
      AND IsProcessed = 0; -- 用标记字段区分已更新/未更新的记录

    SET @RowCount = @@ROWCOUNT;

    COMMIT TRANSACTION;

    -- 批次之间加个短延迟，给数据库时间释放锁、清理日志
    WAITFOR DELAY '00:00:00.5';
END

这里关键是用TOP(@BatchSize)配合标记字段，确保每次只处理未更新的小批量记录，避免重复扫描全表。

2. 开启快照隔离，避免读锁阻塞写操作 #

默认的READ COMMITTED隔离级别下，读操作会加共享锁，可能阻塞你的更新。开启READ COMMITTED SNAPSHOT ISOLATION（RCSI）可以让读操作使用行版本，不用加共享锁，减少冲突：

ALTER DATABASE YourDatabaseName
SET READ_COMMITTED_SNAPSHOT ON;

这个设置需要数据库没有活跃连接，所以最好在维护窗口操作。开启后，你的更新事务不会被其他查询的读锁卡住，反之亦然。

3. 确保更新语句有高效索引，减少锁的范围 #

如果你的更新语句的WHERE条件没有合适的索引，数据库会做全表扫描，这会导致大量的表锁或页锁，大大增加锁冲突的概率。检查一下：

• 你的WHERE子句里的过滤字段（比如用来区分批次的标记字段、更新条件字段）有没有创建非聚集索引？
• 索引是否包含了更新所需的列？（避免书签查找，减少IO和锁时间）

比如给标记字段加个索引：

CREATE NONCLUSTERED INDEX IX_YourTable_IsProcessed ON YourTable(IsProcessed)
INCLUDE (ColumnToUpdate, UpdateCondition);

4. 监控并杀掉阻塞进程 #

有时候锁超时是因为有其他长查询或事务一直持有锁，阻塞了你的更新。你可以用下面的查询找出阻塞源：

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    resource_description
FROM sys.dm_tran_locks
WHERE request_status = 'WAIT';

如果发现有长期阻塞的进程，确认安全后可以用KILL [session_id]杀掉它（注意：生产环境操作前一定要确认！）。

5. 调整LOCK_TIMEOUT（谨慎使用） #

如果上面的方法都试过还是偶尔超时，可以临时调整锁超时时间，但不建议调得太大，只是作为临时应急：

SET LOCK_TIMEOUT 30000; -- 设置为30秒，默认是-1（无限等待）

这个设置只对当前会话有效，所以要在你的脚本开头加上。

最后提醒一下：每次修改脚本后，先在测试环境跑一遍，验证批次大小和逻辑没问题再上生产。祝你这次能顺利跑完5000万条更新！

内容的提问来源于stack exchange，提问作者IvanN