单表更新死锁主因是加锁顺序不一致、索引失效或间隙锁干扰；解决核心是统一IN列表升序、确保索引有效、避免范围查询，并在应用层捕获1213错误重试。
单表更新报死锁，不是数据库出问题了，而是事务对同一张表里的多行加锁时顺序不一致、锁范围失控或索引失效导致的交叉等待。它和“多表操作”无关，纯单表照样死锁。
UPDATE WHERE id IN (3,1,5) 为什么比 WHERE id IN (1,3,5) 更容易死锁
MySQL 的 UPDATE 按 SQL 中 IN 列表的**字面顺序**加锁，不是按主键值排序后加锁。两个事务分别执行：
-
UPDATE t SET x=1 WHERE id IN (3,1,5)→ 可能先锁 id=3，再锁 id=1，最后 id=5 -
UPDATE t SET x=1 WHERE id IN (5,1,3)→ 可能先锁 id=5，再锁 id=1，最后 id=3
只要它们都命中 id=1 和 id=3（或其他重叠行），就可能形成 A 锁了 3 等 1、B 锁了 1 等 3 的 ABBA 循环。
解决方法很简单但必须强制落地：
- 所有批量更新前，应用层对 ID 数组做升序排序，再拼成
WHERE id IN (1,3,5) - ORM（如 MyBatis）动态拼接时，
<if>分支容易打乱顺序，关键事务建议禁用，改用预编译 + 排序后参数绑定 - 不要指望 MySQL 自动重排
IN列表——EXPLAIN看不出加锁顺序，InnoDB 也不做这层优化
WHERE biz_no = 'xxx' 没走索引，等于主动锁全表
如果 biz_no 字段没建索引，UPDATE t SET status='done' WHERE biz_no = 'xxx' 在 REPEATABLE READ 下会触发全表扫描，并为**每一行**加 X locks rec but not gap，还可能对间隙加锁。哪怕只该更新 1 行，实际锁了上千行，和其他事务冲突概率陡增。
排查和修复要点：
- 用
EXPLAIN验证每条更新语句是否走了索引；注意隐式类型转换（比如WHERE biz_no = 123但字段是VARCHAR）会让索引失效 - 复合条件优先建联合索引，例如
WHERE biz_no = ? AND status = ?→ 建(biz_no, status)，不是单独索引 - 避免在索引列上用函数：
WHERE DATE(create_time) = '2026-09-28'无法走create_time索引
REPEATABLE READ 下的间隙锁怎么偷偷锁住你没查到的行
默认隔离级别 REPEATABLE READ 启用 Next-Key Lock（记录锁 + 间隙锁），哪怕你更新的是不存在的记录，只要落在某个索引间隙内，也会被锁住。例如表中有 id=10 和 id=20，执行 UPDATE t SET x=1 WHERE id = 15（无此行），InnoDB 会锁住间隙 (10,20)；此时另一个事务插入 id=15 或更新 id=18，就可能触发死锁。
规避策略要分场景选：
- 确认业务是否真需要 RR：若能接受幻读，直接设
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，InnoDB 会禁用间隙锁 - 单表高频更新尽量避免范围条件，改用主键或唯一键精确匹配
- 实在要范围操作（如
WHERE created_at > '2026-09-20'），考虑拆成多次小批量 + 主键升序，减少间隙重叠
最常被忽略的一点：死锁不是靠调大 innodb_lock_wait_timeout 解决的，它只会让等待更久；重点是确保 innodb_deadlock_detect = ON（默认已开），让 InnoDB 能快速识别并回滚代价小的事务。而应用层必须自己捕获错误码 1213 并重试——这是唯一能闭环的地方。
