mysql默认隔离级别是repeatable read，根本原因是早期statement格式binlog下，read committed会导致主从执行逻辑错位；rr通过next-key lock强制写操作串行化，确保binlog记录与物理执行一致。
MySQL 默认隔离级别是 REPEATABLE READ，根本原因不是“为了更强一致性”，而是早期主从复制依赖 STATEMENT 格式 binlog 时，READ COMMITTED 会导致主库执行逻辑和从库重放逻辑不一致——RR 靠间隙锁强制串行化，堵住了这个漏洞。
为什么 RC + STATEMENT binlog 会主从不一致
STATEMENT 格式只记录 SQL 文本，不记录实际读到的行。RC 下事务内多次 SELECT 可能读到不同快照，导致主库执行顺序和 binlog 记录顺序错位：
- Session A 执行
DELETE FROM t WHERE c_id = 2（尚未提交） - Session B 插入
INSERT INTO t VALUES (100, 2)并提交 - Session A 最终提交 → 主库实际先删后插，但 binlog 按“提交时间”记为先插后删
- 从库回放时严格按 binlog 顺序执行 → 先插再删 → 多出一行或少一行
RC 不加间隙锁，无法阻塞 Session B 的插入，这种错位无法避免。
RR 怎么靠 Next-Key Lock 解决这个问题
REPEATABLE READ 下，InnoDB 对 WHERE 条件涉及的索引范围自动加 Next-Key Lock（行锁 + 间隙锁），本质是让写操作串行化：
-
DELETE FROM t WHERE c_id = 2会锁住c_id = 2对应的整个索引区间 - Session B 的
INSERT尝试往该区间插入 → 被阻塞，直到 Session A 提交或超时 - 结果：两个操作在主库上变成确定性顺序（要么 A 先删完 B 再插，要么 B 先插 A 再删），binlog 记录与物理执行完全对齐
这不是为业务提供“可重复读”语义，而是为复制安全强加的锁机制。
为什么现在还默认 RR，即使已普遍用 ROW binlog
ROW 格式 binlog 记录的是变更前后的行镜像，天然规避语句重放歧义，RC + ROW 完全可保证主从一致。但默认值未改，因为：
- 兼容性：大量 ORM、分库中间件（如
ShardingSphere）隐式依赖 RR 的快照行为和锁语义 - MVCC 行为差异：
REPEATABLE READ事务启动时建一次ReadView，后续所有SELECT都复用；READ COMMITTED每次SELECT都新建，可能破坏某些两次查询比对类逻辑 - 锁开销被忽略：RR 的间隙锁持有时间更长，MVCC 版本链更臃肿，尤其在长事务中容易拖慢 purge 线程
真正容易被忽略的是：RR 的“安全性”只在 STATEMENT binlog 下是刚需；切到 ROW 后，它带来的锁竞争和版本膨胀反而成了纯负担。
