MySQL执行流程中是如何实现Read View以保证可重复读的？-mysql教程-PHP中文网

read view 在可重复读（rr）下于事务首次 select 时创建并全程复用，确保同一事务内多次查询结果一致；它含 creator_trx_id、m_ids、min_trx_id、max_trx_id 四字段，依规则逐行判断版本可见性。

mysql执行流程中是如何实现read view以保证可重复读的？

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_id min_trx_id → 表示修改它的事务在当前事务“看见快照”前已提交，可见
该版本的 trx_id ≥ max_trx_id → 表示修改它的事务在当前事务创建 Read View 后才启动，不可见
该版本的 trx_id ∈ m_ids → 表示修改它的事务当时还活跃（未提交），不可见
该版本的 trx_id ∉ m_ids 且 ≥ min_trx_id → 表示修改它的事务已提交且不在活跃列表中，可见

这个判断过程不依赖锁，纯靠版本链 + Read View 字段计算，所以读操作几乎无阻塞。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

为什么可重复读能防止不可重复读，却对幻读“半解决”

不可重复读被彻底解决，是因为 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 仍可能幻读。