innodb_locks_unsafe_for_binlog=1不能使RR行为完全接近RC，仅禁用间隙锁和临键锁、保留记录锁，但读视图仍复用事务初建版本，不支持每次SELECT新建read view，且破坏binlog安全性。
innodb_locks_unsafe_for_binlog=1 能否让 RR 行为接近 RC
不能完全模拟，但能禁用部分 Next-Key Lock，使锁范围缩小到 Record Lock 为主。它只影响非唯一索引的范围查询（如 WHERE col > 10），对主键或唯一索引的等值查询（WHERE id = 5）无影响——这些仍走 Record Lock，本来就跟 RC 一样。
开启 innodb_locks_unsafe_for_binlog 的实际效果
该参数设为 1 后，InnoDB 在 RR 隔离级别下会跳过间隙锁（Gap Lock）和临键锁（Next-Key Lock），仅在匹配到的记录上加 Record Lock。但它不改变 MVCC 的一致性读视图逻辑：事务仍只创建一次 read view，后续 SELECT 仍不可见其他事务新提交的行（这点和 RC 本质不同）。
- 范围查询（
WHERE idx_col BETWEEN 10 AND 20）不再锁(10,20]区间，只锁实际存在的行 - 插入冲突减少：其他事务可在原间隙中插入新行，不再被阻塞
- 幻读风险回归：同一事务两次执行相同范围 SELECT，可能看到新插入的行
-
SELECT ... FOR UPDATE和UPDATE/DELETE的锁行为变化一致，但SELECT普通读仍不可见新提交数据
为什么它不是“切换成 RC”的安全替代
关键区别不在锁，而在读视图生命周期：
- RC 每次
SELECT都生成新read view，可立即看到已提交变更 - RR 即使关了间隙锁，仍复用事务开始时的
read view，旧事务看不到新提交行 - binlog 安全性受损：设为
1时，语句级 binlog 可能因并发插入导致主从不一致，尤其在INSERT ... SELECT或基于范围的复制场景 - DDL 操作（如
ALTER TABLE）期间该参数无效，锁行为仍按默认 RR 处理
真正想用 RC 锁行为，就该直接改隔离级别
如果业务能接受不可重复读，又希望降低锁竞争、提升并发写入吞吐，直接设 SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED 更干净。强行在 RR 下开 innodb_locks_unsafe_for_binlog=1，等于保留 RR 的读一致性包袱，又丢掉它的幻读防护，还引入 binlog 风险——这是最易被忽略的权衡点。
