非唯一索引等值查询必然带间隙锁
只要走的是普通索引（非唯一），哪怕 WHERE name = 'xxx' 只命中一行，InnoDB 也会加 next-key 锁，即记录锁 + 两侧间隙锁。这不是优化器“多此一举”，而是 RR 隔离级别下防止幻读的刚性要求。
原因很直接：普通索引不唯一，相同值可能被反复插入。如果只锁住已存在的行，新插入的同值行就会逃逸，导致事务内第二次查出更多行——这就是幻读。
- 示例：表
t有普通索引idx_name，当前数据为('a'), ('b'), ('d') - 执行
SELECT * FROM t WHERE name = 'b' FOR UPDATE - InnoDB 实际加三把锁：
lock_mode X,REC_NOT_GAP（锁住 'b' 这条记录）+lock_mode X,GAP（锁住 ('a', 'b')）+lock_mode X,GAP（锁住 ('b', 'd')） - 此时
INSERT INTO t (name) VALUES ('c')会被阻塞，因为 'c' 落在 ('b', 'd') 间隙内
唯一索引等值查询只在“记录存在”时退化为记录锁
主键或唯一索引上执行 WHERE id = 100，只有当该行真实存在，才会退化为纯 REC_NOT_GAP 记录锁；一旦查不到，InnoDB 仍会加间隙锁——比如 id = 2 不存在，它就锁定 (1, 3) 这个间隙。
关键判断依据不是“是不是唯一索引”，而是“查询是否命中真实记录”。可通过 SELECT @@tx_isolation 确认当前是 REPEATABLE-READ，再查 performance_schema.data_locks 验证：
- 看到
LOCK_MODE = 'X,REC_NOT_GAP'→ 纯记录锁（安全） - 看到
LOCK_MODE = 'X,GAP'或'X'（无后缀）→ 含间隙成分（需警惕） - 看到两行锁：一行在普通索引上
LOCK_TYPE = 'RECORD'，另一行在主键上LOCK_TYPE = 'RECORD'，且都带GAP→ 典型 next-key 行为
为什么 SELECT ... FOR UPDATE 和 UPDATE 加锁逻辑一致
很多人误以为只有 UPDATE 才会触发间隙锁，其实 SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 在 RR 下同样遵循 next-key 规则。它们不是“只读”，而是显式声明要控制并发写入范围。
真正区别在于锁类型（S vs X），而非锁粒度。也就是说，哪怕你只是想“查完再决定要不要改”，只要加了 FOR UPDATE，InnoDB 就按写操作的语义加锁——包括封锁间隙。
- 常见踩坑：用
SELECT ... FOR UPDATE做幂等校验（如“查余额够不够再扣”），却没意识到它已阻塞其他事务向同一索引区间插入 - 更隐蔽的问题：多个事务同时查同一个不存在的值（如
name = 'missing'），各自加相同间隙锁，随后又都尝试INSERT→ 死锁高发 -
DELETE的加锁行为与SELECT ... FOR UPDATE几乎完全一致，别指望删比查“松”
绕过间隙锁的代价很实在
没有“优雅绕过”的方案，只有明确取舍：
- 降级到
READ COMMITTED：间隙锁失效，但幻读回归——某些业务能接受（如日志类），金融类基本不可行 - 强制走唯一索引 + 确保记录存在：例如用主键查，且提前确认该 ID 已写入；
FORCE INDEX对非唯一索引无效，InnoDB 不吃这套 - 用
INSERT ... ON DUPLICATE KEY UPDATE替代先查后插：避开显式锁，但需设计好唯一约束
最易被忽略的一点：间隙锁只作用于索引排序后的逻辑位置，不是物理顺序。当有多个普通索引时，InnoDB 按索引定义顺序逐个评估，不是按你 ORDER BY 的字段——这点在复合索引场景下特别容易误判锁范围。
