间隙锁在MySQL的REPEATABLE READ隔离级别下，于范围查询或唯一索引等值查询但记录不存在时触发，锁定索引区间以防止幻读；降为READ COMMITTED可禁用间隙锁，但会引入不可重复读和幻读。
间隙锁在什么情况下会被触发
MySQL 的 REPEATABLE READ 隔离级别下，只要执行的是范围条件（比如 WHERE id > 10、WHERE name LIKE 'a%'），或者唯一索引上的等值查询但记录不存在，InnoDB 就会加间隙锁（Gap Lock）——不是锁住某条记录，而是锁住索引区间，阻止其他事务往这个空隙里插入新行。
常见错误现象：INSERT 被阻塞、事务长时间等待 lock wait timeout exceeded、明明只查一条却卡住其他写入。
- 唯一索引等值查询（
WHERE id = 123）且记录存在 → 只加记录锁，不加间隙锁 - 唯一索引等值查询但记录不存在 → 加间隙锁（锁定前后两个已存在记录之间的空隙）
- 非唯一索引或无索引的等值/范围查询 → 必然涉及间隙锁，甚至可能升级为临键锁（Next-Key Lock）
-
SELECT ... FOR UPDATE或SELECT ... LOCK IN SHARE MODE会放大间隙锁影响范围
降低隔离级别真能解决间隙锁问题吗
把隔离级别从 REPEATABLE READ 改成 READ COMMITTED 后，MySQL 会禁用间隙锁（除外键检查和唯一性检查外），只对实际命中的记录加行锁。这是最直接的规避手段，但代价明确：可能引入不可重复读、幻读。
使用场景：日志类、统计类、报表类业务，允许“两次查结果不一样”，但不能接受写入阻塞；或者你确认当前业务逻辑本身不依赖可重复读语义。
-
READ COMMITTED下，UPDATE和DELETE仅锁住扫描到的记录，不会锁间隙 - 主从复制必须用
ROW格式，否则STATEMENT格式在READ COMMITTED下可能出错 - 某些 ORM（如早期 Django）默认依赖
REPEATABLE READ行为，改隔离级别前需验证事务逻辑是否仍正确 - 全局修改需谨慎：
SET GLOBAL tx_isolation = 'READ-COMMITTED'影响所有新连接，建议按会话设置：SET SESSION tx_isolation = 'READ-COMMITTED'
等值查询怎么绕开间隙锁却不降级隔离级别
核心思路是让 MySQL 确定“只有一条记录匹配”，从而避免走范围扫描路径。关键在索引选择和查询写法。
常见错误现象：明明写了 WHERE id = ?，却还是被加了间隙锁——大概率是因为字段没走索引，或走了非唯一索引，或用了函数/表达式导致索引失效。
- 确保查询字段上有唯一索引（主键或
UNIQUE约束），且查询条件是纯等值、无隐式类型转换 - 避免
WHERE CAST(id AS CHAR) = '123'、WHERE id + 0 = 123这类写法，会导致索引失效，退化为全表扫描+间隙锁 - 用
EXPLAIN确认type是const或eq_ref，而不是range或index - 如果业务允许，用主键代替业务字段查询（比如用
user_id而非username），因为主键一定唯一且高效
为什么有时候加了唯一索引还是被间隙锁
最常被忽略的一点：**唯一索引列允许 NULL**。MySQL 认为多个 NULL 值不违反唯一约束，因此对 WHERE col IS NULL 这种查询，即使 col 是唯一索引，也会走间隙锁逻辑。
另一个隐蔽点是二级唯一索引和聚簇索引的交互：如果查询命中唯一索引但未覆盖所需字段，InnoDB 还要回表查主键，过程中可能触发额外锁范围。
-
UNIQUE(col)允许NULL→WHERE col IS NULL会加间隙锁；改成UNIQUE(col) NOT NULL可避免 - 联合唯一索引中，只有最左前缀匹配时才可能触发间隙锁；比如
UNIQUE(a, b)，WHERE a = 1是范围扫描，仍会锁间隙 -
SELECT ... FOR UPDATE即使只查主键，若语句里带ORDER BY或LIMIT不够精确，优化器也可能扩大扫描范围 - 监控锁等待可用
SELECT * FROM performance_schema.data_locks，但注意它显示的是当前持有锁，不是等待锁
间隙锁不是 bug，是 MVCC 在可重复读下的必要机制；绕开它的本质，是让数据库相信“这次操作不需要防止幻读”。设计阶段就明确每条查询的语义边界，比事后调参更可靠。
