MVCC理解

MySQL的MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种高效的并发控制机制，通过维护数据的多个版本实现读写操作的并行执行，显著提升数据库的并发性能和数据一致性。

MVCC 的实现依赖于：隐藏字段、Read View、undo log。

隐藏字段

• DB_TRX_ID（6字节）：表示最后一次插入或更新该行的事务 id。此外，delete 操作在内部被视为更新，只不过会在记录头 Record header 中的 deleted_flag 字段将其标记为已删除
• DB_ROLL_PTR（7字节）： 回滚指针，指向该行的 undo log 。如果该行未被更新，则为空
• DB_ROW_ID（6字节）：如果没有设置主键且该表没有唯一非空索引时，InnoDB 会使用该 id 来生成聚簇索引

Read View

ReadView（读视图）是 InnoDB 为了实现一致性读（Consistent Read）而创建的数据结构，它用于确定在特定事务中哪些版本的行记录是可见的。

当事务开始执行时，InnoDB 会为该事务创建一个 ReadView，这个 ReadView 会记录 4 个重要的信息：

• creator_trx_id：创建该 ReadView 的事务 ID。

• m_ids：所有活跃事务的 ID 列表，活跃事务是指那些已经开始但尚未提交的事务。

• min_trx_id：所有活跃事务中最小的事务 ID。它是 m_ids 数组中最小的事务 ID。

• max_trx_id：事务 ID 的最大值加一。换句话说，它是下一个将要生成的事务 ID。

Undo log

undo log（回滚日志） 主要有两个作用：

• 当事务回滚时用于将数据恢复到修改前的样子
• 另一个作用是 MVCC ，当读取记录时，若该记录被其他事务占用或当前版本对该事务不可见，则可以通过 undo log 读取之前的版本数据，以此实现非锁定读

在 InnoDB 存储引擎中 undo log 分为两种：insert undo log 和 update undo log：

1. insert undo log：指在 insert 操作中产生的 undo log。因为 insert 操作的记录只对事务本身可见，对其他事务不可见，故该 undo log 可以在事务提交后直接删除。不需要进行 purge 操作
2. update undo log：update 或 delete 操作中产生的 undo log。该 undo log可能需要提供 MVCC 机制，因此不能在事务提交时就进行删除。提交时放入 undo log 链表，等待 purge线程 进行最后的删除

可见性判断

当读取一行数据时，会通过以下规则判断该版本是否可见：

• 如果该版本的DB_TRX_ID小于min_trx_id，说明该版本在创建ReadView时已经提交，可见

• 如果该版本的DB_TRX_ID大于等于max_trx_id，说明该版本在创建ReadView时还未开始，不可见

• 如果该版本的DB_TRX_ID在m_ids中，说明该版本在创建ReadView时还未提交，不可见

• 如果该版本的DB_TRX_ID等于creator_trx_id，说明该版本是当前事务修改的，可见

可见性判断举例

前景知识

事务开始和ReadView创建的时序关系：

1. 事务开始
   1. 当执行 BEGIN 或 START TRANSACTION 时，事务开始
   2. 此时会分配一个事务ID（trx_id）
   3. 但此时并不会创建ReadView
2. ReadView创建
   1. ​​​​​在第一次执行SELECT语句时才会创建ReadView
   2. 不同隔离级别下，ReadView的创建时机不同：
      • READ COMMITTED：每次SELECT都会创建新的ReadView
      • REPEATABLE READ：第一次SELECT时创建ReadView，后续复用

假设我们有一个用户表，包含以下数据：

CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(50),
    age INT
);

INSERT INTO users VALUES (1, '张三', 20);

场景1：事务ID小于min_trx_id（已提交事务）

事务1 (trx_id=100): 开始事务
事务2 (trx_id=101): 开始事务
事务1: 更新 users 表，将张三的年龄改为21
事务1: 提交事务
事务2: 创建ReadView (min_trx_id=101, max_trx_id=102, m_ids=[101])
事务2: 读取 users 表

结果：事务2可以看到更新后的数据（年龄=21）

原因：因为事务1的trx_id(100) < min_trx_id(101)，说明该版本在创建ReadView时已经提交

 场景2：事务ID大于等于max_trx_id（未开始事务）

事务1 (trx_id=100): 开始事务
事务1: 创建ReadView (min_trx_id=100, max_trx_id=101, m_ids=[100])
事务2 (trx_id=101): 开始事务
事务2: 更新 users 表，将张三的年龄改为22
事务1: 读取 users 表

结果：事务1看不到事务2的更新（仍然看到年龄=20）

原因：因为事务2的trx_id(101) >= max_trx_id(101)，说明该版本在创建ReadView时还未开始

 场景3：事务ID在m_ids中（未提交事务）

事务1 (trx_id=100): 开始事务
事务2 (trx_id=101): 开始事务
事务1: 更新 users 表，将张三的年龄改为21
事务2: 创建ReadView (min_trx_id=100, max_trx_id=102, m_ids=[100,101])
事务2: 读取 users 表

 

结果：事务2看不到事务1的更新（仍然看到年龄=20）

原因：因为事务1的trx_id(100)在m_ids中，说明该版本在创建ReadView时还未提交

 场景4：事务ID等于creator_trx_id（当前事务修改）

事务1 (trx_id=100): 开始事务
事务1: 创建ReadView (min_trx_id=100, max_trx_id=101, m_ids=[100])
事务1: 更新 users 表，将张三的年龄改为21
事务1: 读取 users 表

 

结果：事务1可以看到自己的更新（看到年龄=21）

原因：因为该版本的trx_id(100)等于creator_trx_id(100)，说明该版本是当前事务修改的

隔离级别与MVCC

 ​​1. 读未提交（Read Uncommitted）​​

• ​​MVCC 行为​​：​​不使用 MVCC​​，直接读取数据的最新版本（包括未提交的数据）。
• ​​数据可见性​​：事务可看到其他事务未提交的修改（脏读）。
• ​​典型问题​​：脏读、不可重复读、幻读均可能发生。
• ​​适用场景​​：对数据一致性要求极低的场景（如日志记录）。

 ​​2. 读已提交（Read Committed）​​

• ​​MVCC 行为​​：
  • ​​每次 SELECT 生成新 ReadView​​：每次查询时创建新的快照，仅读取已提交的数据版本。
  • ​​写操作使用当前读​​：UPDATE/DELETE 操作会读取最新已提交数据并加锁。
• ​​数据可见性​​：事务内多次查询可能看到不同结果（因其他事务提交导致数据变更）。
• ​​解决的问题​​：脏读（因只读已提交数据）。
• ​​未解决的问题​​：不可重复读、幻读（因无间隙锁）。
• ​​适用场景​​：需避免脏读，但允许不可重复读的场景（如实时统计）。

​​3. 可重复读（Repeatable Read，MySQL 默认级别）​​

• ​​MVCC 行为​​：
  • ​​事务开始时生成固定 ReadView​​：整个事务复用同一快照，确保多次查询结果一致。
  • ​​通过版本链访问历史数据​​：通过 DB_ROLL_PTR 回溯旧版本。
• ​​锁机制补充​​：​​间隙锁（Gap Lock）​​ 阻止范围内新数据插入，解决幻读。
• ​​解决的问题​​：脏读、不可重复读、幻读（InnoDB 通过 MVCC + 间隙锁实现）。
• ​​适用场景​​：需保证事务内数据一致性的场景（如账户余额查询）。

4. 串行化（Serializable）​​

• ​​MVCC 行为​​：​​基本不使用 MVCC​​，主要依赖严格的锁机制（读写均加锁）。
• ​​数据可见性​​：事务串行执行，完全隔离并发操作。
• ​​解决的问题​​：所有并发问题（脏读、不可重复读、幻读）。
• ​​缺点​​：​​性能最低​​，高并发下易引发锁等待和死锁。
• ​​适用场景​​：对数据一致性要求极高且并发量低的场景（如金融清算）。

• 读未提交（Read Uncommitted）：不使用MVCC，直接读取数据的最新版本（包括未提交的数据），脏读、不可重复读、幻读均可能发生。
• 读已提交（Read Committed）​：使用MVCC​
• 可重复读（Repeatable Read，MySQL 默认级别）​
• 串行化（Serializable）​