InnoDB的UPDATE未命中行时锁范围远超预期，因其加的是WHERE条件覆盖索引区间的间隙锁，而非单条记录锁；例如id=500不命中且最近值为100和900时，实际锁定(100,900)整个间隙。
UPDATE没命中行，为什么锁的范围比预期大得多
因为InnoDB加的不是“某条记录”的锁，而是“WHERE条件扫描覆盖的索引区间”上的间隙锁。只要走索引、条件可界定边界、且无匹配行，InnoDB就会按next-key lock规则向上/下找最近存在的索引值，把整个空档（A, B）全锁住——哪怕你只查id = 500，而表中最近的是id = 100和id = 900，那锁的就是(100, 900)这个跨度极大的间隙。
哪些索引结构会让间隙锁范围爆炸式扩大
间隙锁范围取决于索引类型和数据分布，不是SQL写得“精确”就能缩小：
- 普通索引（非唯一）上等值查询：如
UPDATE t SET x=1 WHERE status = 'pending'，即使只有一行匹配，也会锁住该status值在索引页中前驱和后继之间的全部间隙；若该值在索引中分散、或页分裂严重，实际锁定范围可能跨多个页 - 联合索引前缀匹配但后缀未指定：如索引是
(a, b, c)，而条件只有WHERE a = 1 AND b > 10，InnoDB会先定位a = 1的索引子树，再在其中做范围扫描，间隙锁覆盖整个b > 10对应的所有c可能取值区间 - 主键/唯一索引上等值不命中，但相邻记录相距极远：如表中只有
id = 1和id = 1000000两行，执行UPDATE t SET v=1 WHERE id = 500000，间隙锁直接覆盖(1, 1000000)——这是最典型的“大范围”来源
怎么快速判断当前UPDATE锁了多大范围
别依赖EXPLAIN的rows为0就认为“没影响”，真实锁范围必须查运行时状态：
- 执行
SELECT * FROM performance_schema.data_locks WHERE OBJECT_NAME = 't'，重点关注LOCK_MODE含GAP或NEXT-KEY的行，以及LOCK_DATA字段显示的边界值（如100和1000000） - 运行
SHOW ENGINE INNODB STATUS\G，搜索lock_mode X locks gap before rec，它后面紧跟的space id和page number能帮你定位到具体索引页，结合INFORMATION_SCHEMA.INNODB_INDEXES反查该页对应索引的键值分布 - 用并发验证：在事务A执行完未命中UPDATE后，立即在事务B中尝试
INSERT多个不同id值——能插入成功的最大id和最小失败id，就是间隙的实际左右边界
业务代码里最容易忽略的放大点
很多团队以为加了唯一索引就安全，却忽略了数据稀疏性带来的隐性风险：
- 时间戳类字段建了索引，但业务写入集中在某几个小时，其余时段大量空白：如
created_at索引中最近两条记录是'2026-10-14 23:59:59'和'2026-10-15 00:00:01'，中间差2秒，但UPDATE ... WHERE created_at = '2026-10-15 00:00:00'仍会锁住这2秒间隙；而如果最近记录是'2026-01-01'和'2026-10-15'，那间隙就是9个月 - 用UUID或雪花ID作主键，但批量导入历史数据导致ID极度离散：索引树上相邻叶节点物理距离远，逻辑间隙巨大，一次未命中UPDATE可能锁住数万ID跨度
- 误以为
SELECT ... FOR UPDATE和UPDATE锁范围一致——其实UPDATE在RR下必然加next-key lock，而SELECT ... FOR UPDATE在某些优化路径下可能退化为纯record lock（如唯一索引+等值+存在），这点差异会让压测结果和线上表现严重不一致
实际锁范围永远由索引结构和现有数据共同决定，而不是SQL字面意思。越是“看起来只该影响一行”的语句，在数据稀疏或索引设计不匹配时，越容易触发超大间隙锁。
