MySQL在RC级别下仍可能产生Gap Lock，仅限唯一约束或外键检查场景：UNIQUE索引冲突检测（如INSERT ON DUPLICATE KEY）和外键引用表范围扫描时，InnoDB为保障数据一致性主动加锁，属官方允许行为。
RC级别下Gap Lock只在唯一约束检查时触发
MySQL官方明确承认：READ COMMITTED隔离级别本应禁用Gap Lock，但为保证唯一性语义，会在涉及UNIQUE索引（含主键）的冲突检测场景中悄悄启用。这不是bug，是必须付出的代价。
典型触发动作包括：INSERT ... ON DUPLICATE KEY UPDATE、REPLACE INTO、INSERT IGNORE，以及任何可能违反唯一约束的UPDATE。InnoDB必须提前锁定“可能插入成功”的间隙，否则两个事务同时尝试插入同一UNIQUE值，会绕过约束检查造成数据不一致。
- 即使表只有一条记录
id=100，执行INSERT INTO t (id) VALUES (99)仍会锁住间隙(-∞, 100) - 该行为与查询是否命中记录无关，只取决于语句是否需做唯一性校验
-
SELECT ... FOR UPDATE在RC下确实不加Gap Lock；但UPDATE t SET x=1 WHERE id=5若id是唯一索引，InnoDB仍会加Next-Key Lock（含Gap Lock）来覆盖查找路径
外键约束也会强制RC下启用Gap Lock
当表存在FOREIGN KEY约束时，MySQL在RC级别下对被引用表（parent table）执行SELECT或UPDATE操作，若涉及外键列的范围扫描，InnoDB会主动加Gap Lock。
目的是防止子表插入新记录后，父表的外键检查失效。例如：t_child的parent_id外键指向t_parent(id)，事务中执行SELECT * FROM t_parent WHERE id > 100 FOR UPDATE，即使在RC下，InnoDB也会锁定(100, +supremum]区间，阻止t_child插入parent_id=105等值——否则后续父表删除id=105就会破坏参照完整性。
- 该机制由
innodb_locks_unsafe_for_binlog=OFF（默认）控制；设为ON可禁用，但会牺牲外键安全性和主从一致性 -
SHOW ENGINE INNODB STATUS中看到lock_mode X,GAP且事务正在等待insert intention，基本可断定是外键或唯一约束引发
如何确认当前语句是否触发了RC下的Gap Lock
不能只看隔离级别配置，必须结合执行计划和锁信息交叉验证。最直接的方式是复现后立即查INFORMATION_SCHEMA.INNODB_TRX和INFORMATION_SCHEMA.INNODB_LOCK_WAITS，再配合SHOW ENGINE INNODB STATUS输出中的TRANSACTIONS部分。
- 关注
LOCK_MODE字段：X,GAP表示纯间隙锁，X,REC_NOT_GAP是记录锁，X（无后缀）通常代表Next-Key Lock - 检查
LOCK_TRX_ID对应的SQL是否含UNIQUE索引条件、ON DUPLICATE KEY、FOREIGN KEY -
LOCK_DATA显示锁住的索引值范围，如100, 110表示间隙(100, 110)；你要插id = 105，而某行LOCK_DATA是100, 110→ 就是它
INSERT IGNORE和ON DUPLICATE KEY UPDATE也逃不开Gap Lock
别以为加了IGNORE或ON DUPLICATE KEY UPDATE就安全——它们底层仍要申请插入意向锁，并完成唯一性校验路径。只要目标值落在已被其他事务锁定的间隙内，就会阻塞甚至死锁。
- 现象：INSERT一直卡住不返回，
SHOW ENGINE INNODB STATUS里看到waiting for gap before lock或类似提示 - 报错：
Lock wait timeout exceeded或Deadlock found when trying to get lock - 根本原因不是语法糖，而是InnoDB必须确保唯一约束在并发下不被绕过——哪怕你最终不插入，校验过程本身就要锁住“可能插入的位置”
真正容易被忽略的点在于：Gap Lock在RC下的出现，从来不是孤立语句决定的，而是由约束定义+索引结构+当前持有锁的事务共同作用的结果。查锁时只盯SQL，不看INNODB_STATUS里的TRANSACTIONS和LOCKS段，几乎不可能准确定位。
