read committed禁用间隙锁是因隔离语义变化：快照读仅见已提交版本，当前读只锁命中行而不锁间隙，从而消除范围插入阻塞；但唯一约束、外键检查等场景仍保留必要间隙锁。
为什么READ COMMITTED能禁用间隙锁
MySQL的间隙锁（Gap Lock）不是靠开关配置项控制的，而是由事务隔离级别隐式决定的。在REPEATABLE READ下，InnoDB默认启用间隙锁来防止幻读；而切换到READ COMMITTED后，InnoDB会自动禁用大部分间隙锁——仅保留外键检查和唯一约束验证所需的最小范围锁。这不是“关闭功能”，而是隔离语义变更带来的行为差异。
关键点在于：READ COMMITTED下，快照读只看到已提交版本，当前读（如SELECT ... FOR UPDATE）也只锁住实际命中的行，不锁间隙。这直接消除了多个INSERT并发写同一索引范围时的相互阻塞。
- 确认当前级别：
SELECT @@transaction_isolation; - 会话级临时切换：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; - 全局生效（需重启或动态设置）：
SET GLOBAL transaction_isolation = 'READ-COMMITTED';，并写入配置文件my.cnf的[mysqld]段
哪些场景下间隙锁仍会被加
即使设为READ COMMITTED，某些操作仍会触发间隙锁，这是为了保障数据一致性底线，不能绕过：
- 唯一索引等值插入失败时：比如
INSERT INTO users (id, name) VALUES (100, 'Alice')，若id=100已存在，InnoDB仍会对(99,101)这个间隙加锁，防止其他事务同时插入相同值造成唯一冲突 - 外键约束检查：子表插入时需验证父表主键是否存在，会锁定父表对应索引范围
-
SELECT ... LOCK IN SHARE MODE或FOR UPDATE配合范围条件（如WHERE status IN ('pending', 'processing')）仍可能锁住间隙，尤其当索引不是唯一或未覆盖查询条件时
这类残留间隙锁无法通过隔离级别消除，只能靠优化索引设计、拆分大范围条件、或改用更精确的等值查询规避。
切换后必须同步调整的配套配置
READ COMMITTED不是孤立生效的，它和binlog格式、主从复制逻辑强耦合。若忽略以下两点，轻则复制中断，重则主从数据不一致：
-
binlog_format必须为ROW：在READ COMMITTED下，STATEMENT格式的binlog无法正确还原事务效果，会导致从库执行失败或结果偏差。检查命令：SELECT @@binlog_format;，修改方式：SET GLOBAL binlog_format = 'ROW'; - 确认
innodb_locks_unsafe_for_binlog未启用：该参数在MySQL 5.7+已被弃用，若配置文件中还残留，必须删除——它与READ COMMITTED语义冲突，且可能导致不可预测的锁行为 - 应用层需接受“不可重复读”：同一个事务内多次
SELECT可能返回不同结果，例如统计类接口若依赖两次查询差值，需改用单次聚合或引入应用级缓存
如何验证间隙锁是否真正减少
不能只看隔离级别变了就认为生效，得从锁等待链和执行计划里找证据：
- 监控锁等待：
SHOW ENGINE INNODB STATUS\G中重点关注TRANSACTIONS部分，对比切换前后lock struct(s)数量和waiting for this lock to be granted出现频率 - 查锁信息表（MySQL 5.7+）：
SELECT * FROM performance_schema.data_locks;，观察LOCK_MODE字段是否从RECORD GAP或NEXT-KEY大量变为RECORD - 压测对比：用相同并发数执行
INSERT ... SELECT或批量插入，观察Innodb_row_lock_waits和Innodb_row_lock_time_avg指标变化
最易被忽略的是：间隙锁减少不等于“没锁”，只是锁得更窄、更短。如果业务仍集中在极少数热点行（如账户余额更新），行锁竞争依然存在，这时得结合INSERT ON DUPLICATE KEY UPDATE或应用层队列缓冲进一步解耦。
