MySQL MVCC 详解

发布于:2025-07-02 ⋅ 阅读:(46) ⋅ 点赞:(0)

MySQL MVCC 详解

维基百科上关于 MVCC 的介绍:

多版本并发控制(Multiversion concurrency control, MCC 或 MVCC),是数据库管理系统常用的一种并发控制,也用于程序设计语言实现事务内存。
MVCC意图解决读写锁造成的多个、长时间的读操作饿死写操作问题。每个事务读到的数据项都是一个历史快照,并依赖于实现的隔离级别。写操作不覆盖已有数据项,而是创建一个新的版本,直至所在操作提交时才变为可见。快照隔离使得事务看到它启动时的数据状态。

MVCC 的核心是 “数据多版本”,即同一数据在系统中可以存在多个版本,每个事务看到的数据是特定版本的快照。具体来说:

  • 读操作:无需加锁,直接读取数据的某个历史版本,避免了与写操作的冲突。
  • 写操作:只锁定当前操作的数据,不影响其他事务的读操作。

这种机制使得读写操作可以并发执行,大大提高了数据库的并发性能。

MVCC 实现机制

MySQL中,MVCC的实现基于以下基石:

隐藏字段

InnoDB 中,每一行数据除了我们定义的字段外,还会存在一些额外的隐藏列:

  • DB_TRX_ID:事务ID,表示插入或更新该行的最后一个事务的事务标识符;
  • DB_ROLL_PTR:回滚指针,回滚指针指向写入回滚段的 undo log 记录;
  • DB_ROW_ID:行ID,随着新行插入而单调增加。

事务ID

每次启动一个事务,InnoDB 会为其分配一个唯一递增的事务 ID。事务 ID 用于判断数据版本的可见性。

回滚段(Rollback Segment)与 undo 日志

当数据被修改时,InnoDB 会将旧数据复制到回滚段中,并通过DB_ROLL_PTR指针链接到 undo 日志。这些历史版本数据用于支持事务回滚和 MVCC 的读操作。

Read View(读视图)

每个读操作启动时会生成一个 Read View,包含当前活跃事务的列表。Read View 用于判断事务能看到哪些数据版本。Read View 包含以下四个关键属性:

  • creator_trx_id:当前创建 Read View 的事务 ID。用于标识生成该 Read View 的事务。
  • trx_ids:活跃事务列表,创建 Read View 时,当前所有未提交的事务 ID 列表(即活跃事务)。这些事务的修改对当前 Read View 可能不可见,需要根据规则判断。
  • low_limit_id:创建 Read View 时,系统中已分配的最大事务 ID + 1。表示大于等于该值的事务 ID 在 Read View 创建后生成,对当前 Read View 不可见。
  • low_limit_no:删除版本号:用于判断行的删除操作是否对当前事务可见(与 purge 操作相关)。核心是前三个属性。

对于读已提交事务隔离级别,在事务中每次执行查询都会重新创建一次Read View,因此可能会读取到其它事务提交的数据。
对于可重复读事务隔离级别,在事务中只会创建一次Read View,后续每次查询都使用第一次创建的Read View,因此保证了每次读取的数据都是一致的。

流程

  • 数据准备,当前事务隔离级别为 读已提交
    create table t1 (id int primary key, c2 int);
    insert into t1 values (1, 100);
    
  • 事务1
    START TRANSACTION;
    update t1 set c2 = 200 where t1 = 1;
    
  • 事务2 开启并进行查询
    START TRANSACTION;
    select * from t1 where id = 1;
    
  • 事务3
    START TRANSACTION;
    update t1 set c2 = 300 where t1 = 1;
    
  • 事务2第二次次查询
    select * from t1 where id = 1;
    
  • 事务1提交
    COMMIT;
    
  • 事务2第三次查询
    select * from t1 where id = 1;
    commit;
    

在这里插入图片描述
假设上述事务1的事务ID=120,事务2的事务ID=130,事务3的事务ID=140。

对于事务2第一次查询时,事务1先一步开启进行数据修改,并且没有提交,MVCC 的处理流程如下:

  1. 生成 Read View:
    • creator_trx_id:事务 2 的 ID = 130。
    • trx_ids:活跃事务列表,包含事务 1,为 120。
    • low_limit_id:创建 Read View 时,系统中已分配的最大事务 ID + 1 ,假定为131。
  2. 查询操作获取到最新行中的 DB_TRX_ID=120,为事务1修改
  3. 可见性判断:
    • 120 在 trx_ids 中,因此当前数据未提交,对于当前事务不可见;
    • 根据DB_ROLL_PTR查找undo log,事务ID为110,未被其它事务修改,数据可见;
  4. 因此事务2第一次查询结果为 100。

对于事务2第二次查询时,新开启了事务3修改了数据,并且也没有提交,MVCC 的处理流程如下:

  1. 生成 Read View:
    • creator_trx_id:事务 2 的 ID = 130。
    • trx_ids:活跃事务列表,包含事务1,事务3,为 120,140。
    • low_limit_id:创建 Read View 时,系统中已分配的最大事务 ID + 1,假定为141。
  2. 查询操作获取到最新行中的 DB_TRX_ID=140,为事务3修改;
  3. 可见性判断:
    • 140 在 trx_ids 中,因此当前数据未提交,对于当前事务不可见;
    • 根据DB_ROLL_PTR查找undo log,事务ID为120,仍然在 trx_ids 中,被事务1修改,对于当前事务不可见;
    • 继续根据DB_ROLL_PTR查找undo log,事务ID为110,未被其它事务修改,数据可见;
  4. 因此事务2第二次查询结果为 100。

对于事务3第三次查询时,事务1提交,事务3仍然开启,MVCC 的处理流程如下:

  1. 生成 Read View:
    • creator_trx_id:事务 2 的 ID = 130。
    • trx_ids:活跃事务列表,由于事务1已提交,因此只包含事务3,为140。
    • low_limit_id:创建 Read View 时,系统中已分配的最大事务 ID + 1,假定为141。
  2. 查询操作获取到最新行中的 DB_TRX_ID=140,为事务3修改;
  3. 可见性判断:
    • 140 在 trx_ids 中,因此当前数据未提交,对于当前事务不可见;
    • 根据DB_ROLL_PTR查找undo log,事务ID为120,事务已提交,数据可见;
  4. 因此事务2第二次查询结果为 200。