rc级别下gap lock仅在唯一约束或外键检查时启用，用于防止并发插入破坏唯一性或参照完整性，属官方允许的合法场景。
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)，防止另一个事务插入95或99 - 该行为与查询是否命中记录无关，只取决于语句是否需做唯一性校验
- 普通
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部分。
- 关注锁模式字段：
X,GAP表示纯间隙锁，X,REC_NOT_GAP是记录锁，X（无后缀）通常代表Next-Key Lock - 检查
LOCK_TRX_ID对应的SQL是否含UNIQUE索引条件、ON DUPLICATE KEY、FOREIGN KEY关联操作 - 用
EXPLAIN FORMAT=tree确认查询是否走了唯一索引；若走全表扫描，则RC下不可能出现Gap Lock
规避RC下意外Gap Lock的实操建议
多数业务并不需要靠间隙锁保唯一性——应用层重试+数据库唯一索引已足够。真要压降锁冲突，优先从语句设计入手，而非盲目调低隔离级别。
- 避免在高并发写入路径中使用
INSERT ... ON DUPLICATE KEY UPDATE；改用先SELECT再INSERT/UPDATE，并确保SELECT加FOR UPDATE（此时RC下只锁行，不锁间隙） - 删除无实际用途的
FOREIGN KEY约束；若必须保留，评估是否可接受innodb_locks_unsafe_for_binlog=ON（仅限非关键业务库） - 对唯一索引字段的等值更新，显式用主键代替二级唯一索引定位，减少扫描范围——
UPDATE t SET x=1 WHERE pk=123比WHERE email='a@b.com'更安全
Gap Lock在RC下不是失控的异常，而是为原子性与一致性让渡的并发代价。真正危险的不是它存在，是你没意识到它正因唯一性或外键在后台生效。
