read view在事务隔离级别决定的时机生成：rc级别下每次快照读新建，rr级别下仅首次快照读创建并复用，ru不生成，serializable绕过；其生成时机直接决定可见性行为。
Read View在什么时机生成？取决于隔离级别
Read View不是每次SELECT都新建，也不是事务一开启就固定生成——它的生成时机直接由事务隔离级别决定，这是理解MVCC行为的关键起点。
常见错误现象：同一事务中两次SELECT结果不一致，或始终不变，开发者常归因于“缓存”或“SQL写错”，实际是Read View生成策略不同导致的可见性变化。
-
READ COMMITTED：每次执行快照读（即普通SELECT）前，都新建一个Read View；所以能看到其他事务刚提交的新版本 → 出现不可重复读 -
REPEATABLE READ（MySQL默认）：仅在事务内**第一次快照读**时生成Read View，后续所有SELECT复用它 → 同一事务内多次读同一行，结果严格一致 -
READ UNCOMMITTED：根本不生成Read View，直接读最新版本 → 可能脏读，SELECT等价于当前读 -
SERIALIZABLE：退化为加锁读（如SELECT ... LOCK IN SHARE MODE），Read View机制被绕过
Read View的四个核心字段怎么参与判断？
InnoDB检查某条记录是否对当前事务可见时，拿该行的DB_TRX_ID（写入该版本的事务ID）和Read View的四个字段比对。这不是简单大小比较，而是分层过滤逻辑。
容易踩的坑：误以为low_limit_id是活跃事务ID的最大值——它其实是系统已分配过的最大事务ID + 1，涵盖所有历史事务，因此DB_TRX_ID >= low_limit_id意味着“这个版本属于未来事务”，直接排除。
-
creator_trx_id：当前事务自己的ID。若DB_TRX_ID == creator_trx_id→ 自己改的，一定可见 -
trx_ids（或m_trx_ids）：生成Read View时所有未提交事务ID的数组。若DB_TRX_ID在此数组中 → 那个事务还没提交，不可见 -
up_limit_id（或m_up_limit_id）：即trx_ids中的最小值。若DB_TRX_ID → 表示该版本由已提交事务写入，可见 -
low_limit_id（或m_low_limit_id）：下一个将分配的事务ID。若DB_TRX_ID >= low_limit_id→ 不可能属于当前系统，不可见
为什么INSERT不产生版本链，而UPDATE/DELETE会？
版本链只存在于被修改过的行上，本质是Undo Log的组织方式。Read View的可见性判断必须依赖这条链来回溯历史版本，所以理解哪些操作触发链构建，直接影响你对快照读结果的预期。
典型场景：批量导入新数据后立刻做报表查询，发现查不到刚插入的记录——不是数据没写进去，而是该事务尚未提交，且当前查询事务的Read View已生成，trx_ids里包含那个INSERT事务ID，导致新行被过滤掉。
-
INSERT：新行无历史版本，DB_ROLL_PTR为空，不形成版本链；该行的DB_TRX_ID就是插入事务ID -
UPDATE或DELETE：InnoDB先将旧值写入Undo Log，再更新聚簇索引页，并用DB_ROLL_PTR指向刚写的undo记录 → 新旧版本靠指针串成链 - 每次修改都生成新节点，最新版本在链头；回溯时按
DB_TRX_ID逐个比对Read View，直到找到第一个满足可见性条件的版本
如何验证当前事务用了哪个Read View？
MySQL不提供直接查看Read View内容的SQL命令，但可通过组合手段间接确认其行为，这对线上问题排查非常实用。
最容易被忽略的点：Spring的@Transactional默认走REPEATABLE READ，但如果你在事务内先执行了SELECT FOR UPDATE（当前读），再执行普通SELECT（快照读），后者仍复用第一次快照读生成的Read View——不是“事务开始时”，而是“第一次快照读时”。
- 用
SELECT @@tx_isolation确认当前会话隔离级别 - 在事务内连续执行两次
SELECT，中间让另一个事务COMMIT修改同一行 → 若结果不同，说明是READ COMMITTED；若相同，大概率是REPEATABLE READ - 执行
SELECT * FROM information_schema.INNODB_TRX，观察TRX_STARTED时间与你第一次SELECT的时间是否接近，辅助判断Read View生成时刻
