Read View 在可重复读（RR）下于事务首次 SELECT 时创建并全程复用，确保同一事务内多次查询结果一致；它含 creator_trx_id、m_ids、min_trx_id、max_trx_id 四字段，依规则逐行判断版本可见性。
Read View 是在事务第一次 SELECT 时创建的
MySQL InnoDB 的可重复读（REPEATABLE READ）不是靠“每次查询都重算快照”，而是靠事务启动后**第一次执行 SELECT 时生成一个 Read View，并在整个事务生命周期内复用它**。这个行为直接决定了“为什么同一事务中多次读结果一致”。
注意：事务启动（BEGIN 或 START TRANSACTION）本身不触发 Read View 创建；只有碰到第一个 SELECT（或 SELECT ... LOCK IN SHARE MODE / SELECT ... FOR UPDATE）才真正初始化。
- 如果事务只做
INSERT/UPDATE/DELETE，从不查数据，那 Read View 可能一直不创建 - 显式开启只读事务（
START TRANSACTION READ ONLY）也不自动建 Read View，仍要等首个SELECT -
SELECT语句若命中了主键/唯一索引的等值查询，且走的是聚簇索引，InnoDB 会用当前读（SELECT ... LOCK IN SHARE MODE级别），此时可能绕过 MVCC 快照而加锁读最新版本——这和 Read View 无关，属于锁机制范畴
Read View 四个关键字段如何决定数据可见性
每个 Read View 包含四个核心字段：creator_trx_id、m_ids、min_trx_id、max_trx_id。它们共同构成判断某行数据版本是否对当前事务可见的规则链。
当执行 SELECT 时，InnoDB 沿着该行的版本链（由 roll_pointer 连接）从最新版本开始逐个检查，直到找到满足以下任一条件的版本：
- 该版本的
trx_idmin_trx_id → 表示修改它的事务在当前事务“看见快照”前已提交，可见 - 该版本的
trx_id≥max_trx_id→ 表示修改它的事务在当前事务创建 Read View 后才启动，不可见 - 该版本的
trx_id∈m_ids→ 表示修改它的事务当时还活跃（未提交），不可见 - 该版本的
trx_id∉m_ids且 ≥min_trx_id→ 表示修改它的事务已提交且不在活跃列表中，可见
这个判断过程不依赖锁，纯靠版本链 + Read View 字段计算，所以读操作几乎无阻塞。
为什么可重复读能防止不可重复读，却对幻读“半解决”
不可重复读被彻底解决，是因为 Read View 固定后，同一行的多个版本对事务始终呈现相同可见性——哪怕其他事务提交了新版本，只要其 trx_id 不落在当前 Read View 的可见范围内，就不会被看到。
但幻读（SELECT COUNT(*) WHERE balance > 100 结果变多）在纯 MVCC 下依然可能发生，因为新插入的行其 trx_id 可能刚好落在 min_trx_id 和 max_trx_id 之间，且不在 m_ids 中（即插入事务已提交），于是被当前事务“意外”看到。
InnoDB 的应对方式是：在当前读（如 SELECT ... FOR UPDATE）场景下，配合**间隙锁（Gap Lock）** 或 **临键锁（Next-Key Lock）** 封锁索引区间，阻止其他事务在范围内插入。但这仅作用于加锁读，普通 SELECT 仍可能幻读。
- 普通
SELECT：靠 MVCC + 固定 Read View，不锁范围，可能幻读 - 加锁
SELECT：MVCC + 间隙锁，阻止插入，避免幻读 - 因此 MySQL 的
REPEATABLE READ实际上“通过锁机制补足了标准未要求的部分”，但它不是靠 Read View 本身解决幻读
容易被忽略的边界情况：长事务导致的 Read View 滞后
Read View 一旦创建就固定不变，但如果一个事务持续数小时不结束，它持有的 Read View 里的 m_ids 列表会一直包含大量早已提交甚至已崩溃的事务 ID（因为 InnoDB 不会主动清理旧事务信息），导致：
- undo log 无法被 purge，占用磁盘空间持续增长
- 其他事务更新同一行时，需维护更长的版本链，增加 CPU 和内存开销
- 极端情况下，
max_trx_id溢出或版本链过深引发性能抖动
这不是 Read View 设计缺陷，而是使用方式问题：**可重复读的强一致性是以资源消耗为代价的，长事务必须有明确监控和超时机制**。生产环境应避免无意义的长时间空闲事务。
