MySQL — MVCC

文章目录

• MVCC
• [MVCC 实现原理](#MVCC 实现原理)
• • 隐藏字段
  • [undo log](#undo log)
  • • [undo log的用途](#undo log的用途)
    • [undo log类型](#undo log类型)
  • 版本链
  • ReadView

MVCC

InnoDB是一个多版本的存储引擎。它保留有关已更改行的旧版本的信息，以支持并发和回滚等事务性特性。这些信息存储在undo表空间中的数据结构称为回滚段。InnoDB使用回滚段中的信息来执行事务回滚所需的undo操作。它还使用这些信息来构建数据行的早期版本，以实现一致的读取。

MVCC 只在 read-committed 和 repeatable-read两个隔离级别下工作。

MVCC 实现原理

隐藏字段

在mysql中，在实现MVCC时，会为每一个表添加如下几个隐藏的字段：

• 6字节的DATA_TRX_ID：标记了最新更新这条行记录的transaction id，每处理一个事务，其值自动设置为当前事务ID（DATA_TRX_ID只有在事务提交之后才会更新）；
• 7字节的DATA_ROLL_PTR：一个rollback指针，指向当前这一行数据的上一个版本，找之前版本的数据就是通过这个指针，通过这个指针将数据的多个版本连接在一起构成一个undo log版本链；
• 6字节的DB_ROW_ID：隐含的自增ID，如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引。这是一个用来唯一标识每一行的字段；

undo log

undo log 主要用于记录数据被修改之前的日志，在表信息修改之前先会把数据拷贝到undo log里。

当事务进行回滚时可以通过undo log 里的日志进行数据还原。

undo log的用途

保证事务进行rollback时的原子性和一致性，当事务进行回滚的时候可以用undo log的数据进行恢复。

用于MVCC快照读的数据，在MVCC多版本控制中，通过读取undo log的历史版本数据可以实现不同事务版本号都拥有自己独立的快照数据版本。

undo log类型

insert undo log：代表事务在insert新记录时产生的undo log , 只在事务回滚时需要，并且在事务提交后可以被立即丢弃

update undo log ：事务在进行update或delete时产生的undo log ; 不仅在事务回滚时需要，在快照读时也需要；

所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除

版本链

MySQL的每行记录逻辑上其实是一个链表。

MySQL行记录中除了记录业务数据外，还有隐藏的 DATA_TRX_ID 和 DATA_ROLL_PTR

当然，这个链表存在于 undo log 中，和最新版本的数据不在一起。

每次更新后，都会将旧值放到一条 undo log 中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_ptr 属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。

另外，每个版本中还包含生成该版本时对应的 事务id。

ReadView

当我们的隔离级别为 RR 或 RC 时：每开启一个事务，系统会给该事务会分配一个事务 Id，在该事务执行第一个 select 语句的时候，会生成一个当前时间点的事务快照 ReadView。

而 RC 和 RR 生成 ReadView 的策略是有差别的：

• RC隔离级别的事务在每次查询开始时都会生成一个独立的 ReadView。
• RR隔离级别的事务在第一次读取数据时生成ReadView，之后的查询都不会再生成，所以一个事务的查询结果每次都是一样的。

RC和RR隔离级别的实现，其核心处理逻辑就是判断记录的所有版本中哪个版本是当前事务可见的处理

因此，ReadView有以下四个重要变量来判断记录是否对当前事务可见：

m_ids ：创建 ReadView 时当前系统中活跃的事务 Id 列表，可以理解为生成 ReadView 那一刻还未执行提交的事务，并且该列表是个升序列表。
m_up_limit_id ：低水位，取 m_ids 列表的第一个节点，因为 m_ids 是升序列表，因此也就是 m_ids 中事务 Id 最小的那个。
m_low_limit_id ：高水位，生成 ReadView 时系统将要分配给下一个事务的 Id 值。
m_creator_trx_id：创建该 ReadView 的事务的事务 Id。

这样在访问某条记录时，只需要按照下边的步骤进行判断：

1. 如果被访问版本的 trx_id 与 ReadView 中的 m_creator_trx_id 值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问。
2. 如果被访问版本的 trx_id 小于 ReadView 中的 m_up_limit_id（低水位），表明被访问版本的事务在当前事务生成 ReadView 前已经提交，所以该版本可以被当前事务访问。
3. 如果被访问版本的 trx_id 大于等于 ReadView 中的 m_low_limit_id（高水位），表明被访问版本的事务在当前事务生成 ReadView 后才开启，所以该版本不可以被当前事务访问。
4. 如果被访问版本的 trx_id 属性值在 ReadView 的 m_up_limit_id 和 m_low_limit_id 之间，那就需要判断 trx_id 属性值是不是在 m_ids 列表中，这边会通过二分法查找。如果在，说明创建 ReadView 时生成该版本的事务还是活跃的，该版本不可以被访问；如果不在，说明创建 ReadView 时生成该版本的事务已经被提交，该版本可以被访问