UPDATE在RR级别下会因索引缺失、范围条件或间隙锁而锁住远超预期的行或间隙；例如无索引时全表扫描逐行加X锁，主键等值更新也会锁(前驱值,当前值)间隙，导致INSERT被阻塞。
这不是“只更新一条数据”导致的死锁，而是这条语句实际锁住的不止一行——尤其在 REPEATABLE READ 隔离级别下，UPDATE 可能因索引缺失、范围条件或间隙锁，锁住远超预期的记录或间隙。
为什么 UPDATE ... WHERE id = ? 会触发间隙锁？
当 id 字段没有索引（或索引失效），InnoDB 无法快速定位目标行，就会走聚簇索引全表扫描。此时每条记录都会被加上 X 锁，且因 RR 级别默认启用间隙锁机制，还会对扫描路径上的间隙加锁——哪怕只命中 1 行，也可能锁住几十甚至整张表的间隙。
- 常见诱因：
WHERE id = ?中的id是VARCHAR类型，但传入的是数字（如WHERE id = 123），触发隐式类型转换，导致索引失效 - 另一个典型场景：该字段有索引，但
UPDATE语句被优化器判定为“可能扫描多行”，比如配合了OR、函数包裹（WHERE CAST(id AS CHAR) = '123'）或统计信息过期 - 验证方式：执行
EXPLAIN FORMAT=TRADITIONAL SELECT * FROM t WHERE id = ?，看key是否为NULL或rows明显偏大
SHOW ENGINE INNODB STATUS 里怎么看真实锁范围？
执行后重点看 LATEST DETECTED DEADLOCK 区块中每个事务的 WAITING FOR THIS LOCK TO BE GRANTED 和 HOLDS THE LOCK(S) 两部分：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 若出现
lock_mode X locks gap before rec或lock_mode X locks rec but not gap后面还跟着n bits XXX（位图长度很大），说明锁住了大量间隙或记录 - 注意
space id和page no：相同页号 + 大量rec锁，大概率是全表扫描加锁；若分散在多个页，可能是唯一索引正常行为 - 对比两个事务的
query id和 SQL，确认是否一个在UPDATE，另一个在INSERT或DELETE相邻主键值——这是间隙锁冲突的铁证
为什么主键更新也会和插入冲突？
主键本身是聚簇索引，但 InnoDB 的临键锁（Next-Key Lock） = 记录锁 + 前驱间隙锁。例如表中已有 id = 1, 5, 10，执行 UPDATE t SET x=1 WHERE id = 5，不仅锁住 id=5 这一行，还会锁住 (1,5) 这个间隙。此时另一个事务执行 INSERT INTO t (id, ...) VALUES (3, ...) 就会被阻塞——它要往 (1,5) 插入，而该间隙已被第一个事务持有 X 间隙锁。
- 这种死锁在高并发 ID 分配（如雪花 ID、业务自增）+ 主键范围查询混合场景极常见
- 解决思路不是去掉间隙锁，而是让所有写操作都“精准命中”：确保
WHERE条件走主键或唯一索引，避免任何可能导致范围扫描的写法 - 临时规避：将隔离级别降为
READ COMMITTED（SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED），该级别下不使用间隙锁，但需评估幻读风险
真正危险的从来不是“更新一行”，而是你没意识到那条 UPDATE 其实锁了一整片区域。查 EXPLAIN、看 INNODB STATUS 中的锁模式、确认索引有效性——这三步做完，90% 的“单行更新死锁”就自然浮出水面了。
