背景在读写混合的OLTP负载中，READ COMMITTED下的每条一致性读通常都要重新打开Read View。若两次读取之间没有读写事务进入或离开活跃事务集合，那么关闭旧视图且重新构建并不会带来新的快照信息，却仍然会产生多余的同步开销。原有实现无法直接判断活跃事务状态是否发生变化，因此复用条件比较保守。当前复用条件不满足时，线程就会进入事务系统保护下的视图重建流程。当并发线程较多时，重复的同步和重建操作会放大共享事务状态上的开销。我们的优化思路是为活跃事务状态增加版本标记，并让Read View保存创建时看到的版本。如果两个版本一致，则说明视图依据的状态没有发生变化，那么可以跳过视图重建；如果版本发生变化，那么仍然进入原有的重建路径。原理 InnoDB通过MVCC实现非锁定一致性读。一条记录经过多次修改后，旧内容会保存在undo log中，形成多个历史版本。执行一致性读时，InnoDB创建Read View，记录当时仍活跃的读写事务ID以及事务ID的取值范围。读取记录时，InnoDB将记录版本的事务ID与这些信息比较；如果当前版本不可见，就沿undo log继续查找更早的版本。 Read View中的关键数据包括： ●m_ids：创建快照时仍然活跃的读写事务集合。 ●m_up_limit_id：活跃事务中的最小事务ID，小于该值的版本通常可见。 ●m_low_limit_id：创建快照时尚未分配的下一个事务ID，大于或等于该值的版本不可见。 ●m_low_limit_no：purge判断历史版本能否清理时使用的边界。 ●m_creator_trx_id：创建该视图的事务ID。 Read View本身不保存记录内容，只保存判断记录版本是否可见所需的事务信息。只要活跃事务集合和相关事务ID没有变化，已有的Read View就能得到相同的可见性判断结果。原有复用逻辑原有视图打开路径只有在以下条件同时满足时才会复用旧视图。 ●当前事务属于autocommit non-locking事务。 ●旧Read View的活跃事务集合为空。 ●旧视图的m_low_limit_id等于当前max_trx_id。这段逻辑通过“视图是否为空”和m_low_limit_id间接判断旧视图能否使用。即使旧视图记录了活跃事务，只要两次打开视图之间没有事务加入或退出，那么它仍可能有效，但上述条件会直接放弃复用。复用失败后，线程会进入受事务系统保护的视图重建路径。复用条件要覆盖这种情况，就必须直接记录活跃事务集合是否发生变化。版本跟踪机制新的实现分别在事务系统和Read View中维护一个版本信息：事务系统保存活跃事务状态的当前版本，Read View保存创建时观察到的版本。该版本号与MySQL版本无关，也不参与记录可见性的大小比较。读写事务加入或退出活跃事务集合时，全局版本号递增，旧Read View中保存的版本号也就失效。两个版本相等，说明自该视图创建以来，没有读写事务加入或退出活跃事务集合，旧视图可以继续使用；版本不相等，则进入原有的加锁重建流程。设计与实现记录版本创建Read View时，系统在同一保护范围内取得活跃事务快照及其边界信息，同时保存当时的全局版本。这个版本标记说明该Read View是基于哪一版活跃事务状态建立。更新版本读写事务加入或退出活跃事务集合，都会改变后续Read View的内容。那么当事务状态发生这两类变化时，全局版本会递增：版本递增发生在活跃事务状态真正变化之前。这样，旧Read View会先被标记为过期，并发线程不会在状态更新期间继续把它当作最新的视图使用。以下两条路径都会递增版本号。 ●新读写事务取得事务ID并加入活跃事务集合。 ●读写事务完成并从活跃事务集合、序列化列表中移除。在需要频繁关闭Read View的场景中，关闭动作只改变视图状态并保留对象。下次打开时，再根据版本决定复用还是重建，关闭路径上的同步开销也随之减少。校验版本新的视图打开路径先比较视图版本和全局版本。两个版本一致时，视图先恢复为active状态，再以原子方式读取一次全局版本：若 Read View 版本 != 全局版本：进入加锁重建否则：先标记为 active，再原子读取全局版本若第二次读取仍相同：直接复用否则：恢复 closed，进入加锁重建第一次比较可以快速排除已经失效的视图。如果两次检查之间发生事务状态变化，第二次读取会发现全局版本已经变化，当前线程就放弃复用并进入重建流程。只有两次比较都一致，视图才会直接复用。第二次读取用来获取第一次比较之后发生的事务状态变化。 Read View的复用还需要处理与purge线程的并发关系。清理线程会根据视图状态判断某个快照是否仍可能被使用。如果复用线程在版本检查完成后才把视图恢复为active，清理线程可能在这段时间内忽略这个即将重新使用的视图。因此，校验顺序是先恢复active状态，再进行原子版本确认。如果确认失败，视图重新设为closed并进入重建路径。这样在整个复用确认窗口内，清理线程都会把该视图视为有效快照，避免提前清理仍可能被访问的历史版本。优化前后对比对比项优化前优化后复用依据检查事务类型、视图状态以及版本边界比较视图版本与全局版本非空Read View 不进入快速复用路径活跃事务集合未变化时可以复用并发变化检测依赖保守条件避免误用状态变化前递增版本，打开时二次确认关闭路径关闭时伴随额外同步操作可先标记关闭，在下次打开时决定复用或重建快速路径开销条件不满足时进入完整重建版本一致时避免链表操作和视图重建这项改动增加的开销，是在读写事务加入和退出时各执行一次原子版本递增。版本一致时，可以省去以下操作。 ●进入事务系统保护范围。 ●重新取得活跃事务快照及相关边界。 ●重建并登记新的Read View。该优化不会改变Read View的可见性规则，也不会改变READ COMMITTED和REPEATABLE READ的隔离语义。改变的只是内部生命周期管理方式，SQL能够看到的数据范围不变。结论版本跟踪为事务系统和Read View记录同一份活跃事务状态的版本。两次打开视图之间没有读写事务加入或退出时，已关闭的Read View通过两次版本校验后即可恢复使用；版本不一致时，仍走原有的加锁重建流程。这一改动不改变MVCC可见性规则，减少的是Read View管理过程中的全局互斥、链表操作和重复构建。在8C16G的规格下，Sysbench只读场景的测试结果为性能提升5%以上。