MySQL在REPEATABLE READ级别下通过事务首次快照读时生成的ReadView实现不可重复读的解决：ReadView包含m_ids、min_trx_id、max_trx_id和creator_trx_id，基于DB_TRX_ID与这些字段比对决定行可见性，且整个事务中复用同一ReadView，确保多次读取结果一致。
MySQL 在 REPEATABLE READ（RR）级别下能解决不可重复读，核心不在于“锁住所有行”，而在于每个事务启动时生成的 ReadView 快照——它决定了你能看见哪些版本的数据。这个快照一旦生成，整个事务期间就固定不变。
ReadView 是什么？它什么时候生成？
ReadView 是 InnoDB 为当前事务构造的一个“可见性判断快照”，里面记录了：当前活跃事务 ID 列表（m_ids）、最小未提交事务 ID（min_trx_id）、最大已分配事务 ID（max_trx_id），以及创建该视图的事务自身 ID（creator_trx_id）。
关键点是：它只在事务中第一次执行 SELECT（非锁定读）时生成，不是在 BEGIN 或 START TRANSACTION 时生成。
- 如果事务 A 执行
BEGIN后一直没查数据，等 5 秒再执行SELECT，那它的ReadView就会包含这 5 秒内新开启但尚未提交的事务 ID - 如果事务 A 连续执行两次
SELECT，第二次不会重新生成ReadView，所以看到的数据版本和第一次完全一致 -
UPDATE/DELETE等写操作不依赖ReadView，而是基于最新行版本 + 加锁逻辑判断能否修改
RR 下怎么判断某行是否可见？
InnoDB 对每一行的隐藏字段 DB_TRX_ID（最后修改该行的事务 ID）与当前 ReadView 做比对，规则如下：
- 若
DB_TRX_ID ：说明这行在当前事务可见前就已提交 → 可见 - 若
DB_TRX_ID >= max_trx_id：说明这行是当前事务之后才开启的事务写的 → 不可见 - 若
DB_TRX_ID在m_ids列表中：说明写这行的事务还没提交 → 不可见 - 若
DB_TRX_ID == creator_trx_id：自己改的 → 可见
这个判断过程完全无锁、无等待，纯靠版本号比较，所以 SELECT 性能高，且天然保证“同一事务内多次读结果一致”——也就是不可重复读被规避了。
为什么 RC 级别做不到？
READ COMMITTED 每次执行 SELECT 都会生成一个新的 ReadView，也就是说：
- 事务 A 第一次
SELECT时，事务 B 还没提交 → 看不到 B 的修改 - 事务 B 提交后，事务 A 第二次
SELECT→ 新建ReadView，此时 B 已不在活跃列表中 → 看得到 B 的修改 - 两次结果不同 → 不可重复读发生
RR 则卡死在第一次的 ReadView，哪怕 B 提交了，只要不在初始活跃列表里，A 就永远看不见——除非 A 显式 COMMIT 后开新事务。
容易忽略的边界：幻读为什么还在？
很多人误以为 RR 下 ReadView 能挡掉幻读，其实不能。因为 ReadView 只管“已有行”的可见性，不管“新插入的行”是否存在。
当事务 A 执行 SELECT * FROM t WHERE c = 10，它通过 ReadView 确保看到的都是“当时已存在且可见”的行；但事务 B 插入 c = 10 的新行并提交后，这行的 DB_TRX_ID 很可能小于 A 的 min_trx_id（比如 B 是个很早开启但刚提交的事务），于是 A 第二次查询时就会看到它——这就是幻读。
RR 真正靠 next-key lock（间隙锁 + 行锁）来压制幻读，但这只在加锁读（如 SELECT ... FOR UPDATE）或 DML 场景生效；普通 SELECT 仍走 MVCC + ReadView，不加锁，也就拦不住新插入的满足条件的行。
