间隙锁仅在repeatable read隔离级别下生效，且需满足索引查询和当前读两个条件；范围查询的开区间触发间隙锁，其锁定范围随索引实际值动态变化。
间隙锁只在可重复读隔离级别下生效
MySQL的间隙锁不是默认开启的“通用功能”，它只在REPEATABLE READ隔离级别下被InnoDB主动使用。如果你把隔离级别设为READ COMMITTED，哪怕SQL一模一样，间隙锁也会被禁用——InnoDB改用纯记录锁（Record Lock），此时幻读可能发生，但并发性能通常更好。
常见错误现象：开发同学看到SELECT ... FOR UPDATE阻塞了插入，以为是“锁太狠”，却没检查SELECT @@transaction_isolation;，结果发现数据库其实是READ COMMITTED，那根本不会出间隙锁——真正阻塞你的可能是别的锁，比如行锁或意向锁。
使用场景上，线上OLTP系统多数用默认RR，所以间隙锁实际影响广泛；但若业务能容忍不可重复读（比如报表类查询、日志归档），降级到RC是最快规避间隙锁副作用的方式。
必须走索引 + 当前读才会触发间隙锁
两个硬性条件缺一不可：WHERE条件必须命中索引（主键、唯一索引、普通索引都行），且语句必须是当前读（SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE、UPDATE、DELETE）。
容易踩的坑：
- 写
WHERE age > 25但age列没索引 → InnoDB退化为全表扫描，不加间隙锁，但可能升级为表锁（TABLE LOCK），更伤并发 - 写
SELECT * FROM t WHERE id > 10但加了ORDER BY name导致索引失效 → 实际执行计划走全表，间隙锁不生效，但性能极差 - 用
SELECT ... FOR UPDATE查非索引字段（如WHERE status = 'pending'且status无索引）→ 同样不触发间隙锁，但锁住所有扫描过的行，等效于慢速表锁
验证是否走索引：务必先跑EXPLAIN，确认key列非NULL，type不是ALL。
范围查询的开区间才是间隙锁的“开关”
间隙锁不是对“查到的数据”加锁，而是对“可能插入新数据的位置”加锁。关键看条件是否形成开区间或半开区间：
WHERE id > 10 AND id → 锁<code>(10, 20)这个间隙（左开右开）WHERE id >= 10 AND id → 锁<code>[10, 20]对应记录 + 间隙(10, 20)（临键锁Next-Key Lock）-
WHERE id = 15（唯一索引）→ 只锁记录本身（Record Lock），不锁间隙 -
WHERE id IN (10, 15, 20)→ 等价于三次等值查询，不触发间隙锁
注意：LOCK_DATA字段在performance_schema.data_locks里显示的是间隙端点，比如值为10, 20，代表锁的是(10, 20)，不是某一行的id=10或id=20。
缩小范围、拆事务、换隔离级别是主要优化手段
间隙锁本身无法“关闭”，只能控制其影响范围。优化核心是减少它被触发的机会和持续时间：
- 把
WHERE created_at > '2025-01-01'改成WHERE created_at BETWEEN '2025-01-01' AND '2026-01-01'，明确边界，避免锁住未来所有时间点 - 避免在大事务里做宽泛范围查询；把一个扣库存+发消息+写日志的大事务，拆成“扣库存（带FOR UPDATE）→ 提交 → 发消息 → 写日志”三段，让间隙锁尽早释放
- 监控死锁日志时，如果频繁出现
*** (1) WAITING FOR THIS LOCK TO BE GRANTED: gap lock on index ...，说明间隙锁正在成为瓶颈，优先考虑加索引或调低隔离级别 -
innodb_lock_wait_timeout设太小（如5秒）会导致重试风暴，设太大（如300秒）会让问题暴露滞后；建议设为30~60秒，并配合应用层幂等重试
最常被忽略的一点：间隙锁的“间隙”是动态计算的，取决于索引页中**当前实际存在的值**。比如索引有[1,5,10]，WHERE id > 3会锁(3,5)和(5,10)，但如果中间插入了7，下次同样查询就可能锁(3,5)、(5,7)、(7,10)——这个细节决定了压测环境和生产环境的锁行为可能完全不同。
