MySQL InnoDB默认RR隔离级别通过事务启动时生成的静态ReadView实现可重复读，配合MVCC判断数据版本可见性；为防幻读，范围查询自动使用Next-Key Lock锁住间隙。
MySQL InnoDB 默认用 REPEATABLE READ（RR），不是因为它“更安全”或“更高级”，而是它在读多写少的 OLTP 场景下，用 MVCC + Next-Key Lock 的组合，刚好能堵住 不可重复读 和 幻读 两个洞，同时不牺牲太多并发性能。
RR 隔离级别下，为什么两次 SELECT 同一条记录结果总一样？
关键在事务启动时生成的 ReadView。它不是动态刷新的，而是一次性快照——记录了当前活跃事务 ID 列表、最小未分配事务 ID（min_trx_id）、最大已提交事务 ID（max_trx_id）。
后续所有普通 SELECT（即快照读）都基于这个 ReadView 判断某行数据的版本是否可见：只有当该行的 trx_id 小于 min_trx_id，或在活跃事务列表里找不到对应 ID，才被当前事务看到。
这意味着：哪怕其他事务中途提交了修改，只要你的事务没结束，ReadView 不变，你看到的就永远是事务开始那一刻的数据版本。
常见错误现象：
- 误以为
SELECT总是读最新数据 —— 其实 RR 下它只认自己事务启动时的ReadView - 在长事务中反复查同一条记录，发现值不变，但实际已被别人改过并提交 —— 这不是 bug，是 RR 的设计目标
RR 真的完全解决了幻读吗？为什么还要加 Next-Key Lock？
单纯靠 MVCC 只能解决“同一行数据多次读取不一致”的问题（即不可重复读），但对“新插入的行突然出现在范围查询结果里”（幻读）无能为力——因为新插入的行没有历史版本可追溯，Undo Log 里压根没它的影子。
所以 InnoDB 在 RR 下对范围查询（比如 SELECT * FROM t WHERE id > 10）自动升级为 Next-Key Lock：即行锁 + 间隙锁的组合。它不仅锁住现有匹配的记录，还锁住这些记录之间的“间隙”，阻止其他事务往里面插新数据。
使用场景：
-
UPDATE ... WHERE或DELETE ... WHERE带范围条件时，InnoDB 默认加Next-Key Lock -
SELECT ... FOR UPDATE或LOCK IN SHARE MODE也是当前读，同样触发Next-Key Lock - 纯
SELECT（快照读）不加锁，但受ReadView限制，看不到新插入的行 —— 这是 MVCC 层面的“幻读屏蔽”，不是锁层面的
RC 和 RR 的 ReadView 生成时机差异，直接影响可见性
READ COMMITTED（RC）每执行一次快照读，就重新生成一个 ReadView；而 REPEATABLE READ（RR）只在事务第一次执行快照读时生成，之后复用。
这就导致同一个事务中：
- RC 下：两次
SELECT可能读到不同结果，只要中间有别的事务提交了修改 - RR 下：两次
SELECT结果必然一致，哪怕中间有大量事务提交
参数差异直接影响行为，不是配置项开关，而是引擎层硬编码逻辑。你改不了 RR 事务里 ReadView 的复用策略，也改不了 RC 的每次重建逻辑。
性能影响：
- RR 的
ReadView复用减少了判断开销，但会延长活跃事务列表的生命周期（因为要保证旧ReadView仍能正确判断可见性），可能拖慢 purge 线程清理Undo Log - RC 虽然每次判断更“准”，但频繁构造
ReadView有轻微 CPU 开销，且更容易遇到高并发下的可见性判断竞争
Undo Log 版本链怎么配合 ReadView 找到“该看哪一版”？
InnoDB 每行数据背后藏着两个隐藏字段：DB_TRX_ID（最后修改该行的事务 ID）和 DB_ROLL_PTR（指向 Undo Log 中上一个版本的指针）。它们构成一条从最新到最老的单向链表。
当需要读取某行时，InnoDB 从最新版本开始，顺着 DB_ROLL_PTR 往前遍历，对每个版本检查其 DB_TRX_ID 是否满足当前 ReadView 的可见性规则。第一个满足的版本，就是你要读的值。
容易踩的坑：
- 长事务不提交，会导致
Undo Log版本链无法被 purge，ibdata1文件持续膨胀 -
SELECT查询越复杂、扫描行越多，遍历版本链的开销越大 —— 尤其在大量更新后又做范围查询时 -
INSERT不产生旧版本，但UPDATE和DELETE会，所以写多的表，Undo Log增长更快
真正难处理的不是 MVCC 本身，而是它和锁机制的边界模糊处：快照读不加锁，但当前读必须加锁；RR 用 MVCC 挡住不可重复读，又靠 Next-Key Lock 挡住幻读。这两套机制在代码里是交织的，不是开关式切换。一旦混用 SELECT 和 SELECT ... FOR UPDATE，或者在事务里穿插 DML，可见性行为就会跳变。理解这点，比记住“RR 能防幻读”重要得多。
