RR隔离级别下间隙锁是防止幻读的刚性机制，只要当前读+索引+范围条件就必加next-key lock；其范围由B+树结构决定而非WHERE字面，且生命周期贯穿整个事务。
RR隔离级别下间隙锁不是“偶尔阻塞”，而是按设计必然扩大锁定范围——只要走索引+当前读+范围条件，InnoDB就默认加next-key lock，锁住记录和它前后的间隙。这不是bug，是防止幻读的刚性代价。
RR下哪些SQL会无感触发间隙锁
开发者常以为“只查到一行就不锁间隙”，但实际只要满足三个条件：隔离级别为REPEATABLE READ、WHERE走索引（主键/唯一/普通索引均可）、语句是当前读（SELECT ... FOR UPDATE、UPDATE、DELETE），就可能加间隙锁。
-
WHERE id > 10（主键）→ 锁(10, +∞)，哪怕表里只有id = 11这一行 -
WHERE name LIKE 'a%'（name是普通索引）→ 锁所有匹配前缀的索引间隙，不止命中行 -
WHERE status = 1 AND created_at > '2026-07-01'（联合索引(status, created_at)）→ 锁扫描路径上的全部间隙 -
WHERE id = 5（唯一索引）但该行**不存在** → 不锁记录，只锁(prev, next)间隙，比如(3, 8)
为什么EXPLAIN看着没问题，插入还是被卡住
常见错觉：EXPLAIN显示type = range、key = idx_id，就认为“锁得准”。但间隙锁范围不由SQL写的WHERE字面决定，而由B+树索引的实际结构决定——InnoDB会沿着索引定位到第一个满足条件的位置，再向右扫描直到不满足，把中间所有间隙都纳入next-key lock。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 表中
id值为1, 3, 7, 10，执行UPDATE t SET x=1 WHERE id BETWEEN 4 AND 8 FOR UPDATE→ 实际锁(3, 7]和(7, 10)，而非(4, 8) - 即使只更新
id = 7这一行，也会连带锁住(3, 7]（含记录）和(7, 10)（纯间隙） - 用
performance_schema.data_locks查LOCK_DATA字段，看到的值是间隙端点（如3, 7），不是被修改的行值
间隙锁阻塞的本质是插入意向锁冲突
间隙锁本身允许并发持有（多个事务可同时锁同一间隙），真正导致阻塞的是后续的INSERT操作需要申请insert intention lock——它与间隙锁互斥。一旦两个事务各自持有一个间隙锁，又都试图往同一间隙插数据，就会形成循环等待。
- 事务T1执行
SELECT * FROM t WHERE id = 5 FOR UPDATE（id=5不存在）→ 在(3, 8)加间隙锁 - 事务T2执行相同语句 → 同样在
(3, 8)加间隙锁（不阻塞，间隙锁间兼容） - T1执行
INSERT INTO t VALUES (5, ...)→ 需要insert intention lockon(3, 8)→ 被T2的间隙锁阻塞 - T2执行同插入 → 被T1的间隙锁阻塞 → 死锁触发
最易被忽略的一点：间隙锁的生命周期绑定整个事务，不是单条语句。哪怕你SELECT ... FOR UPDATE只为了校验，之后还要调用RPC、发MQ、等第三方响应，这期间间隙锁一直占着，其他写入全被堵死。缩锁范围、拆事务、改隔离级别，三者必须选一个动真格的。
