【华为云MySQL技术专栏】MySQL8.0 InnoDB ReadView的原理及性能优化

关注

原创 2025-06-06 14:56:34 1.1k 阅读 AI 写同款· GEO 优化 ›

本文分享自华为云社区《华为云MySQL8.0 InnoDB ReadView的原理及性能优化》，作者：GaussDB 数据库

1. 背景

在我们刚接触MySQL数据库时，就知道了四个渐进的隔离级别：读未提交（READ UNCOMMITTED，简称RU）、读已提交（READ COMMITTED，简称RC）、可重复读（REPEATABLE READ，简称RR）和可串行化（SERIALIZABLE）。

在生产环境中最常用的是RC和RR，二者最主要的区别是同一个事务中间，不同时间点执行的快照读（区别于LOCK IN SHARE MODE和SELECT…FOR UPDATE的加锁读）结果的一致性。

在RC隔离级别下，同一个事务内，不同时间点调用的快照读可能会读到不同的结果，原因是两次读之间可能会有新的数据修改被提交，即RC永远会读到最新的已提交数据。而RR隔离级别则能保证，同一个事务内，不同时间调用的快照读结果的一致性。

从RC到RR，一个主要的区别是解决了不可重复读的问题。通俗意义上讲，是RR提供了更严格的隔离级别。但是，更严格的隔离级别，却不一定会引起更大的性能开销。例如，很多用户在将生产业务迁移到云上的MySQL数据库之前，通常会对照白皮书进行性能测试，但在使用sysbench工具，对最常见的读写混合模型进行数据库性能测试时，遇到了隔离级别更严格的RR性能更好的情况，而且这种性能优势随着并发数增大变得更明显。常见的16U规格下，256个并发读写混合模型，RR的QPS比RC高出了10%以上，这使用户感到困惑。

那么，RR与RC的查询结果这种用户层面的功能区别，在MySQL内部是怎么实现的？另外，为什么在sysbench读写混合场景下RR会比RC表现出更好的性能？

ReadView主要用于实现事务的隔离级别，作为InnoDB实现多版本并发控制（MVCC）的核心组件之一，本文将分析InnoDB ReadView在RR和RC隔离级别下的实现细节和差异，并探讨除了快照读一致性功能的差异之外，ReadView对性能的影响。

2. ReadView可见性的基本实现

ReadView是InnoDB事务中的一种视图，记录了某个事务执行时，其他活跃事务的快照。

（活跃事务：已开启但尚未进行回滚（rollback）或提交（commit）的事务。）

该快照中活跃事务对数据的任何修改，都不应对本次快照读可见。通过判断ReadView记录的活跃事务，即可判断来自于其他并行事务的数据修改，是否对当前事务可见，从而决定查询结果。

在InnoDB代码中，使用的类为ReadView。当事务中发生快照读取时，会调用trx_assign_read_view接口给事务赋ReadView。对于RR隔离级别，这个赋ReadView的动作，发生在事务的第一次快照读时；对于RC隔离级别，这个动作发生在每次快照读时。

2.1 ReadView的关键成员变量

下文介绍类ReadView与查询可见性、查询结果强相关的关键成员变量。其赋值都在这条链路里：

trx_assign_read_view
->MVCC::view_open
->ReadView::prepare

m_creator_trx_id

该ReadView所属事务自身的ID，主要用于判断某条记录的修改是否属于事务自身。

m_low_limit_id

含义为：所有事务ID（下文简称TRX_ID）>=m_low_limit_id的事务产生的数据变动，一定对该ReadView不可见。其赋值为

m_low_limit_id = trx_sys_get_next_trx_id_or_no();

trx_sys_get_next_trx_id_or_no获取事务系统中下一个未分配事务的ID。这个ID的事务，一定大于ReadView创建后给成员变量赋值的时刻，事务系统中最大活跃事务的ID。换言之，此时ID为m_low_limit_id的事务一定没有发生。所以ReadView必然不应该看到大于等于m_low_limit_id的事务。

ids_t m_ids

ids_t是一个单独的类，接口类似STL的自定义容器。m_ids记录了ReadView创建瞬间，自身之外所有活跃读写事务ID的集合，其排列有序，能保证ids_t::front()接口返回最小值。其赋值也较为直观，ReadView::copy_trx_ids在外层调用保证持有全局的事务系统锁trx_sys_t::mutex(下文随代码习惯，简写为trx_sys->mutex)后,直接从全局的事务系统中，拷贝自身所在事务之外的，所有活跃读写事务的ID即可。

  if (!trx_sys->rw_trx_ids.empty()) {
    copy_trx_ids(trx_sys->rw_trx_ids);
  } else {
    m_ids.clear();
  }

m_ids内的所有TRX_ID，在ReadView::prepare赋值的时刻，都没有被提交，都不应对ReadView可见。此外，由于其有序性，相关接口直接采用二分法判断某个事务ID是否在其中。

*读写事务：最常见的BEGIN;或者START TRANSACTION；开启的就是读写事务，会根据事务开启时间，自增地获得一个非0的事务ID。只有START TRANSACTION READ ONLY ;显式开启的只读事务才会获得为0的事务ID。

m_up_limit_id

含义为：所有 TRX_ID< m_up_limit_id小于该值的事务，一定对该ReadView可见。m_up_limit_id的赋值依赖于m_ids。

m_up_limit_id = !m_ids.empty() ? m_ids.front() : m_low_limit_id;

当视图创建时刻：如果事务系统中没有其他活跃读写事务，导致m_ids为空时，该值就等于m_low_limit_id，可见的范围恰好是上文所述“看不到TRX_ID>=m_low_limit_id” 的补集；如果存在其他活跃读写事务，m_ids非空，则对该有序集合调用front()接口获取最小值。由于其有序性，TRX_ID小于最小活跃事务的所有事务，一定是已提交状态，必然对该ReadView可见。

trx_id_t m_low_limit_no

含义为：如果一个Undo Log的TRX_ID<m_low_limit_no，说明当前ReadView不再需要依赖这份Undo Log读取数据。如果一个Undo Log的TRX_ID不被所有存在的ReadView需要，那就说明所有的事务都不需要回溯到这一Undo Log之前，读历史数据，那么这份Undo Log可以被purge。该成员变量的赋值：

m_low_limit_no = trx_get_serialisation_min_trx_no();

右值中的函数调用的含义为：事务系统中，正在提交，但没有真正落盘持久化的事务中，最小事务的TRX_ID。对于已经提交、且持久化的事务，只需读取实际存在的物理页面即可，不需要Undo Log去读更老的版本。

综上所述，ReadView不直接管理数据，只管理一系列的事务ID；通过比较数据修改所属事务ID与ReadView prepare时刻决定可见性的成员变量，决定这项数据修改的可见性。

m_up_limit_id/m_low_limit_id这一对后缀同为 limit_id的成员变量直接用于事务可见性判断，确定了事务对视图可见性的上限和下限，直接使用比较运算符就能快速判断：

范围为TRX_ID< m_up_limit_id，一定可见；范围为 TRX_ID>=m_low_limit_id的事务，一定不可见。在这两个范围之外，即，满足以下条件的事务：m_up_limit_id<=TRX_ID< m_low_limit_id，对于该ReadView的可见性，则依赖于其是否属于m_ids。在ReadView：：prepare执行的时刻，仍未提交或回滚的活跃事务，在m_ids内，则对于该ReadView不可见；不在其中的则对于该ReadView可见。

此外，m_low_limit_no功能相对独立，不直接用于事务对视图可见性的判断，而是ReadView基于创建时刻已经确定的对Undo Log的需求，对Undo Log purge 系统的反馈。

2.2 ReadView的主要接口

基于以上判断逻辑，ReadView类对外提供了以下主要接口，决定了某个ReadView可见的其他事务，从而直接影响查询结果。

changes_visible

判断ReadView是否可见某一个事务ID对数据的修改，常见的使用场景是快照读场景，与某条记录Undo Log上的事务ID及聚簇索引记录上的事务ID进行比对。在存在多个Undo Log版本的情况下，直接决定了要回溯到哪个Undo Log。

其判断逻辑即上述m_up_limit_id/m_low_limit_id/m_ids范围的判断逻辑。

sees

也用于事务对ReadView可见性的判断，与changes_visible的区别是，sees接口仅用于判断ReadView是否可见某一个事务ID对二级索引的修改，仅被lock_sec_rec_cons_read_sees调用。相比changes_visible接口，只判断入参的TRX_ID< m_up_limit_id，不判断TRX_ID>=m_up_limit_id 的事务是否属于m_ids。该接口的设计有一种乐观的思想，即其返值为true时，被判断的事务ID对ReadView一定可见；但其返false时，对ReadView也不一定不可见，此时会再回到聚簇索引判断可见性，常用于优先走二级索引的查询，节省一部分回表判断的开销。sees接口的入参为二级索引的TRX_ID，该TRX_ID的意义是修改过二级索引记录的最大事务ID，通过page_get_max_trx_id接口获取。因此，当它小于当前ReadView的m_up_limit_id时，该页面的所有有效记录一定对该ReadView可见。

3. ReadView的管理和复用

上文介绍了单个ReadView对象中，判断其他并行活跃事务对数据修改可见性的基本逻辑。

高并发场景下，不同的隔离级别会导致并行的多个事务产生多个ReadView。如果不设置相应的管理、复用机制，必然会带来额外的内存和性能开销。在MySQL服务端进程下，所有的ReadView统一由隶属于事务管理系统（trx_sys）中的MVCC类成员mvcc下的成员变量m_views和m_free管理，这两者的数据结构均为链表。

其中，m_views链表管理两种ReadView：

(1) 当前正在有事务使用的活跃ReadView；

(2) 事务已经提交，对应ReadView暂时不活跃，但仍有可能被直接复用的ReadView（下文简称“非活跃ReadView”）。

m_free链表管理已经不再需要被使用的ReadView。在事务需要创建新的ReadView时，会优先从m_free中取出已有老ReadView类的对象，再调用prepare接口重新对成员变量赋值，会覆盖m_free中老的ReadView对象的数据。

这么做可以直接复用一个已申请好的ReadView，避免反复调用ReadView构造函数导致的性能开销、内存碎片。

trx_assign_read_view通过事务结构体trx_t中ReadView类型成员变量read_view指针的值，以及ReadView的成员变量m_closed判断该ReadView的状态，再决定是否重新生成ReadView，或是复用已有ReadView。

如果该ReadView为空指针，必然要调用MVCC::view_open产生新的ReadView。当m_free链表为空时，直接new一个；非空时，直接从链表中取出一个，然后调用ReadView::prepare重新赋值。

如果该ReadView不是空指针，首先判断该ReadView是否活跃，以下函数使用位运算直接判断ReadView指针的最低有效位。判断逻辑如下：

static bool is_view_active(ReadView *view) {
    ut_a(view != reinterpret_cast<ReadView *>(0x1));
    return (view != nullptr && !(intptr_t(view) & 0x1));
}

对于可能被复用、没有直接被挂入m_free链表、暂时被置为非活跃的ReadView，MySQL巧妙地使用了位运算的小技巧：只将trx_t成员变量read_view指针的最低有效位从0置为1，即可使用该指针自身的值作为非活跃的判断条件，避免了额外标记的内存开销。而该指针需要被复用时，只需将最低有效位从1置回0，即可恢复为曾经活跃的ReadView的正确内存地址。

这种判断方法可行的原因是：在MVCC::get_view中，动态申请内存的方法是在堆内存上获取ReadView结构，申请出的内存地址需满足内存对齐要求，通常为alignof(max_align_t)整数倍。alignof(max_align_t)的值，视平台而定。现代系统中的常见值为8或16，而8或16整数倍的内存地址，其二进制最低位一定为0。因此，内存地址最低位为非0的ReadView，一定不是正常动态申请途径获得的。

如果该ReadView指针最低有效位非1，说明该ReadView活跃，就可以直接复用；如果其最低有效位为1，便能确保这个ReadView一定在MVCC::m_views中，且不在MVCC::free_views链表中。这表示该ReadView仅是不活跃了，但在下一个段落所述的场景下，仍可在不修改其成员变量的情况下被复用，具体逻辑在 MVCC::view_close 中展开。

进入MVCC::view_open后，如果满足以下条件，可以直接将非活跃ReadView的重新置为活跃后复用，避免对ReadView::prepare接口的再次调用与由此引起的，对事务系统整体的MUTEX锁trx_sys->mutex的竞争：

事务是自动提交（autocommit，简称 AC）的只读（read-only，简称 RO）事务，且是非锁定（non-locking，简称 NL）的，即文章开头所述的快照读。

其指向的非活跃 ReadView，通过将最低有效位从 1 置回 0 得到的正确地址，读取到的成员变量满足以下条件：

（1）创建时，没有其他活跃事务，成员变量 m_ids 为空集合。

（2）创建之后，没有新的读写事务产生。

代码里的判断条件为：

void MVCC::view_open(ReadView *&view, trx_t *trx) {
…
  if (view != nullptr) {
    uintptr_t p = reinterpret_cast<uintptr_t>(view);
//先复原最后一位为0，得到原先的正确地址
    view = reinterpret_cast<ReadView *>(p & ~1);

// trx_is_autocommit_non_locking函数判断他是AC+NL的快照读，该接口的社区注释也说，这样的话他一定是只读的。
// view->empty() 判断其m_ids为空
    if (trx_is_autocommit_non_locking(trx) && view->empty()) {
      view->m_closed = false;
// ReadView::prepare对m_low_limit_id的赋值是同一个函数trx_sys_get_next_trx_id_or_no，如果再次调用返回值一致，那就说明没有新的读写事务产生。
      if (view->m_low_limit_id == trx_sys_get_next_trx_id_or_no()) {
// 此时，指针已被复位，m_closed也被置0，ReadView重新活跃。
        return;
      } else {
…
}
…
}

满足以上条件的事务（下文随社区代码注释简称AC-RO-NL事务），可以直接复用最低有效位由1复原回0的正确ReadView地址。

除了上述活跃ReadView直接复用和非活跃ReadView的特殊情况之外，其他场景下trx_t结构体的非空read_view指针都会直接失效。具体步骤如下：

（1）获取锁并移除老 ReadView。

持trx_sys->mutex锁之后，把老ReadView从m_views链表中移除；

（2）获取新的 ReadView。

如果MVCC::m_free的链表中已有ReadView对象，则直接取其内存地址，否则重新调构造函数；

（3）准备新的 ReadView。

调用上述prepare接口，对各事务ID相关的成员变量重新赋值完毕后，该m_closed标记被置为false，作为一个全新的ReadView使用。

上文提到了活跃ReadView之外的两种状态：

（1）直接被置入m_free，后续可能直接被覆盖的ReadView；

（2）仍处于m_views中的非活跃ReadView。

活跃ReadView转化为这两种不同状态的触发条件是不一致的，关键在于调用MVCC::view_close及调用时的入参own_mutex。该参数直接影响ReadView自身的标记、成员变量及其在m_view、m_free链表中的状态。

当MVCC::view_close函数入参的own_mutex为true时，执行以下操作“

（1）还原ReadView的正确地址：

将m_creator_trx_id置为TRX_ID_MAX，使用运算位（p & ~1）将指针的最后一位置为0；

（2）移动 ReadView：

将其从MVCC::m_views链表中移除，挂到MVCC::m_free链表的尾部。

此时说明该ReadView的信息不再需要被使用，只是预留了一个内存结构给之后申请的ReadView，避免重复调用构造函数的性能问题。位运算置0的动作，只是为了保证从m_free取内存结构时的正确性。

（3）更新事务结构体：

所属事务结构体trx_t自身的成员变量read_view也会被置为空指针，以确保下一次快照读取时一定会调用prepare接口获取全新的ReadView。

这种own_mutex为true的传参，会出现在会话断开，调用trx_disconnect_from_mysql时，以及RU和RC的隔离级别下，事务内单个查询完毕之后。在解锁表的流程中，调用路径为：

mysql_unlock_read_tables
->…
->ha_innobase::external_lock
-> MVCC::view_close(…, own_mutex=true)

因此，在RC隔离级别下，非自动提交（non-autocommit）的读写事务在活跃状态下，即使两个相邻select之间没有新事务被开启，第一次查询的老ReadView也会被挂入m_free链表。trx_t的成员变量read_view被置空，也保证了新ReadView必须通过ReadView::prepare重新赋值。

RC隔离级别每次都会读到最新提交的原因，就是上述逻辑中，同一事务内每次新的查询都会根据当前时刻并发事务的提交状态重新初始化ReadView。

而在RR隔离级别下，ReadView在事务中第一次快照读时产生。同一个事务内，不会像RC那样，在每次快照读完毕后都在上述链路中调own_mutex为true的view_close。从第一次快照读开始，直到事务提交，trx_t->read_view保持活跃，且其用于判断数据修改可见性的关键成员变量m_ids、m_low_limit_id和m_up_limit_id皆保持不变。

此外，在changes_visible函数内，额外使用m_creator_trx_id确定自身的修改一定可见。这样就能保证，除事务自身的修改之外，后续的快照读与事务内第一次快照读结果一致。这就是可重复读的实现机制。

当MVCC::view_close的入参own_mutex为false时，使用(p | 0x1)将trx_t::read_view 指针的最低位设置为1，并且将m_closed成员变量置true，但不会将其置入MVCC::m_free链表。

view_close的这种传参主要出现在RR隔离级别下，且仅由trx_commit_in_memory调用。其判断条件为如下：

① trx_t的成员变量read_view非空（RC隔离级别下，own_mutex为true的view_close将read_view置空的情形已经不满足）

② 事务是autocommit且non-locking的，或者事务是只读的，或者读写事务没有产生任何数据修改。

满足上述条件的ReadView在事务提交后，不被置入m_free链表的原因是其可能被上文所说的AC-RO-NL事务复用。

4. ReadView的性能瓶颈和优化

4.1 mutex导致的性能瓶颈

关于RR和RC的性能差别，“严格的”RR反直觉地比RC性能更好的现象，很大程度上受压测模型与由此引起的ReadView数量的影响。

在某44核X86物理机，使用社区版8.0.32进行sysbench标准读写模型的压测。测试环境包括250张、每张25000行的表，512并发时，发现RR的QPS约49万，而RC的QPS约41万。反而是RR性能更好。

Perf抓取cpu-time的火焰图热点后，用RR火焰图作为perf diff的比较基线，发现其比RC节省的时间是：

14.87%    -14.66%  mysqld  [.] TTASEventMutex<GenericPolicy>::spin_and_try_lock

TTASEventMutex<GenericPolicy>::spin_and_try_lock是InnoDB自身实现的Mutex接口。单独使用perf report观察RC隔离级别下这多出的约14%的互斥锁（mutex）时间开销，主要集中分布在两个流程中：

1. 6.52% ha_innobase::external_lock：调用view_close前后，会持有trx_sys->mutex。

2. 7.10% MVCC::view_open：在sysbench标准读写模型下，显然无法享受上文AC-RO-NL事务的优化，每次重新调用ReadView：：prepare时，会持有trx_sys->mutex。

trx_sys->mutex这把大锁，会在多个流程中被持有，在高并发下容易引起冲突、锁等待。在Sysbench标准读写压测模型下，单个事务中有多条select SQL语句，在RC隔离级别下，每条SQL语句都产生新的ReadView；而RR隔离级别下，则会共用第一次快照读的ReadView。因此，该模型下RC的总的ReadView请求数量多，导致trx_sys->mutex冲突显著变多。

因此，RR、RC在高并发下性能差别的本质，是同一事务中快照读数量的差别，及由此引起的ReadView请求数量的差别和trx_sys->mutex冲突程度的差别。

4.2 开源社区的性能优化补丁

在MySQL 8.0版本中，社区通过 bug 修复对全局事务管理系统的互斥锁trx_sys->mutex的冲突产生的ReadView性能劣化，以bugfix的形式做了两个优化，这些优化集中在8.0.26版本。

Bug #27933068

引入一把新的mutex trx_sys_t::serialisation_mutex：其核心思想是将事务系统中一部分的成员变量用这把新的互斥锁隔开，与trx_sys->mutex不互相干扰。这些变量包括serialisation_list等。

优化前：新锁隔离的所有相关的成员变量，都共用全局的trx_sys->mutex。

优化后：新锁独立管理的成员变量，涉及到最大事务ID的生成、Show Engine InnoDB Status打印、Undo Log的持久化等关键步骤。

Bug #32832196（及8.0.27后续修复Bug #33000142）

原事务管理系统 rw_trx_set 的管理方式：

事务管理系统 trx_sys 使用成员变量 rw_trx_set 管理事务 ID 与事务结构体 trx_t 指针的映射关系，rw_trx_set的数据结构为map，键为事务ID，值为trx_t指针。单个事务管理系统trx_sys_t结构下，只有一个rw_trx_set，因此，只要涉及到从事务ID找事务结构体，判断trx_t成员变量的场合，都会持有trx_sys->mutex的大锁。

优化后的分片管理：

将 rw_trx_set 改造为固定数量 TRX_SHARDS_N=256 个分片的形式，每个分片的 map 独立持锁。

当对上述键值关系的读写请求产生时，事务管理系统直接用事务ID对256取余的方式确定分片的位置，再对分片加一把独立于trx_sys->mutex的细粒度的锁，减少了trx_sys->mutex的冲突。

此外，在RR隔离级别下，也会因为上述社区原生实现中，MVCC::view_close将ReadView置非活跃的行为，导致性能问题。

AC-RO-NL事务的限制：

AC-RO-NL事务能直接复用MVCC::m_views中非活跃，但条件是非常严苛的：老ReadView创建时，没有其他活跃事务，且老ReadView创建之后，没有新的读写事务产生。对于有持续读写请求的场景，显然很难满足。

非活跃ReadView的堆积：

为了将此小众场景能复用的非活跃ReadView留在m_views链表中，链表的尾部会挂着大量的m_closed=true的ReadView。

purge系统的影响：

在InnoDB的 purge系统的后台线程中，会拷贝最老的活跃ReadView，调用路径为trx_purge->MVCC::clone_oldest_view-> MVCC::get_oldest_view，此过程也会全程持有 trx_sys->mutex。

MVCC::get_oldest_view从MVCC::m_views链表尾部开始遍历，直到找到一个m_closed=false的活跃ReadView。如果链表尾部堆积了大量 m_closed=true 的非活跃 ReadView，MVCC::get_oldest_view的持锁时间上升，阻塞其他并行事务拿trx_sys->mutex, 直接影响其他事务的开启。

5. 总结

本文首先通过ReadView的关键成员变量、接口介绍了其基于活跃事务ID实现快照读、判断数据修改可见性的原理。从ReadView的视角解释了RR、RC这两个隔离级别本质的差异。之后，通过分析InnoDB事务系统对ReadView的管理、复用机制，指出了其关键的性能瓶颈在于事务系统的互斥锁，并基于此解释了标准sysbench压测模型下RR和RC性能差别的原因。最后，针对ReadView的上述性能瓶颈，介绍了社区高版本对其的优化，着重将事务系统的互斥锁拆分为更细粒度。

关注“华为云开发者联盟”，了解更多技术动态。