MySQL可重复读级别下：为何Select创建Read View，增删改却不创建？

先明确一个核心：Read View 是 InnoDB 用来实现可重复读隔离级别的关键，它的作用是帮事务判断「哪些历史数据版本是当前事务可见的」——本质是为了保证读操作的一致性。那为什么写操作不需要它？咱们拆开说：

1. Select 为什么需要 Read View？ #

在可重复读隔离级别下，事务第一次执行普通 SELECT（非加锁读）时，InnoDB 会生成一个 Read View，这个视图里包含了当前所有活跃事务的 ID。之后事务里的所有读操作，都会基于这个 Read View 去版本链里找符合可见性规则的历史版本——这样就能保证在整个事务周期内，读到的数据是一致的，不会被其他并发事务的修改影响。

比如你在事务里第一次读了一条数据，之后其他事务修改了这条数据并提交，你再读的时候还是会看到第一次读的版本，这就是 Read View 帮你固定了读的快照。

2. 写操作（Update/Insert/Delete）为什么不需要 Read View？ #

写操作的核心诉求不是「读一致的快照」，而是定位到最新的数据版本，然后进行修改并保证并发安全：

• 当执行 UPDATE/DELETE 时，InnoDB 会直接找到数据的最新版本，然后尝试加行锁（如果锁成功才会继续）。修改后，会把旧版本写入 undo log 形成版本链——这个版本链是给其他需要读快照的事务用的，而当前写事务自己不需要用 Read View 来判断可见性，因为它要操作的就是最新数据。
• INSERT 更简单，直接写入新数据，没有历史版本需要判断，自然不需要 Read View。

回到你给出的操作例子：

mysql> begin; Query OK, 0 rows affected (0.00 sec)
mysql> update z set b =1 where a =1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0

你的事务只执行了 UPDATE，没有触发任何普通读操作，所以 InnoDB 不会生成 Read View——因为根本不需要它来做可见性判断，写操作走的是完全不同的逻辑链。从你提供的事务状态信息里看不到 Read View 相关内容，这完全符合预期：只有当事务需要读取快照数据时，才会生成这个视图。

补充：加锁读会生成 Read View 吗？ #

比如 SELECT ... FOR UPDATE 这种加锁读，它其实是和写操作类似的逻辑——直接获取最新数据并加锁，所以也不会生成 Read View。只有普通的快照读（不加锁的 SELECT）才会触发 Read View 的创建。

内容的提问来源于stack exchange，提问作者rud wei