最直接有效的方式是把事务隔离级别从repeatable read降到read committed——这会全局禁用间隙锁，只对实际命中的行加记录锁，写入并发能力通常能提升2～5倍；需配合binlog_format = row并避免索引失效。
最直接有效的方式是把事务隔离级别从REPEATABLE READ降到READ COMMITTED——这会全局禁用间隙锁，只对实际命中的行加记录锁，写入并发能力通常能提升2～5倍。其他所谓“关闭”方式要么已弃用，要么副作用远大于收益。
为什么改隔离级别是最靠谱的选择
MySQL的间隙锁不是独立开关，而是REPEATABLE READ隔离级别为防止幻读所依赖的核心机制。想“关掉”它，本质是换一套并发控制逻辑：
-
READ COMMITTED下，InnoDB只在真正修改/查询到的记录上加Record Lock，不锁间隙；INSERT不再被无关UPDATE阻塞 - 同一事务内多次
SELECT可能返回不同结果（不可重复读），但绝大多数业务场景（如订单状态更新、日志写入、消息消费）完全可接受 - 必须配合
binlog_format = ROW，否则主从数据可能不一致；检查命令：SHOW VARIABLES LIKE 'binlog_format'; - 仅会话级设置（
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED）无效，需全局生效：SET GLOBAL tx_isolation = 'READ-COMMITTED';
别碰innodb_locks_unsafe_for_binlog
这个参数在MySQL 5.7.20+已被标记为废弃，8.0中彻底移除。即使旧版本强行设为1，它只是让RR级别下“部分跳过”间隙锁，行为不可控且与binlog格式强耦合，极易引发主从不一致。线上环境严禁使用。
索引失效比间隙锁更致命
很多人以为“关了间隙锁就万事大吉”，却忽略了更常见的性能杀手：没走索引导致的全表扫描加锁。哪怕在RC级别下：
- WHERE条件对索引列用了函数（如
WHERE DATE(create_time) = '2026-10-14'）→ 索引失效 → 锁所有扫描行 - 隐式类型转换（如
WHERE user_id = '12345'而user_id是INT）→ 可能放弃索引 → 实际锁住成千上万行 - 低基数字段（如
status IN ('pending', 'processing')）即使有索引，优化器也可能判定全表扫描更快 → 锁范围失控 - 务必先跑
EXPLAIN SELECT ... FOR UPDATE，确认key列非NULL、type不是ALL
真正影响并发的从来不是“要不要间隙锁”，而是“锁得准不准、放得快不快”。RC级别只是收窄了锁范围，但如果SQL本身没走索引，你只是把表锁换成了慢速行锁阵列。
