大事务锁表主因是长时间持锁及锁升级；应拆分批量操作为小事务并显式提交，确保WHERE条件有匹配顺序的高效索引。

大事务为什么会让业务表锁死

根本原因不是“事务太大”，而是它长时间持有行锁、页锁甚至升级为表锁，而其他业务查询或更新又恰好要访问同一资源。InnoDB 在 UPDATE 不走索引时会全表扫描并加间隙锁（Gap Lock），SQL Server 则可能因锁升级（Lock Escalation）直接把 5000 行的行锁合并成 OBJECT 级别锁——这时整张表就不可写，连 SELECT ... FOR UPDATE 都会排队等。

用 TOP + 循环拆分 UPDATE/DELETE

把一次性处理 10 万行的 UPDATE 拆成每次只改 1000 行的小事务，能大幅缩短单次锁持有时间，降低锁升级概率。关键点不在“循环”本身，而在每次迭代后显式 COMMIT（或让存储过程在每个批次后结束隐式提交）。

• 必须用 WHERE 条件配合 TOP (1000)，不能只靠 OFFSET/FETCH，否则每次仍需扫描全部匹配行
• 推荐用主键或时间字段做驱动条件，例如：WHERE create_time @last_id，避免重复处理
• SQL Server 中禁用 SET LOCK_TIMEOUT 来“防锁”，它对锁升级和死锁完全无效，反而掩盖真实问题

确保 WHERE 字段有高效索引

没有索引的 UPDATE 或 DELETE 是锁表头号诱因。InnoDB 会退化为全表扫描+间隙锁；SQL Server 可能触发锁升级到 OBJECT 级别。索引不是建了就行，得看是否覆盖查询模式。

• 联合索引字段顺序必须匹配 WHERE 中的 AND 顺序，例如 WHERE status = 'pending' AND created_at ，索引应为 <code>(status, created_at)
• 避免在索引列上用函数，WHERE YEAR(created_at) = 2026 会让索引失效，改用 created_at >= '2026-01-01' AND created_at
• SQL Server 中，如果语句里用了 IN (SELECT ...)，务必确认子查询返回结果集小且有索引，否则容易引发嵌套循环导致长持锁

把非数据库操作移出事务边界

RPC 调用、日志落盘、JSON 序列化、消息队列投递这些动作，一旦放在 BEGIN TRAN 和 COMMIT 之间，就会无谓延长事务生命周期。哪怕只是 200ms 的外部延迟，也可能让锁等待从毫秒级变成秒级，进而触发锁升级或死锁。

• 事务内只做纯粹的读写：SELECT、INSERT、UPDATE、DELETE、sp_executesql
• 所有网络 I/O、文件写入、加密计算、外部 API 调用，一律放到 COMMIT 之后
• 若需保证最终一致性，用本地事务 + 消息表（outbox pattern），而不是跨服务两阶段提交

最容易被忽略的是触发器和外键级联操作——它们悄无声息地扩大事务影响范围，可能让一个简单的 UPDATE 实际锁住三张表。上线前务必用 sys.dm_tran_locks 或 SHOW ENGINE INNODB STATUS 抓锁视图，验证实际锁粒度是否符合预期。