MVCC多版本并发控制

MVCC

1.概要

MVCC(Muti-Version Concurrency Control)

作用：在数据库管理系统中，实现对数据库的并发访问

原理：维护一个数据的多个版本，使没有读-写冲突概念

好处：读-写冲突不加锁，降低开销，提高并发性能

2.Innodb实现原理

MVCC其实是一个概念。MySQL使用快照读来实现MVCC概念中的一个非阻塞读功能。

2.1 快照读和当前读

• 当前读：读取记录的最新版本

读取时要保证和其他事务不能并发修改，通过加锁实现

select lock in share mode;
select for update;
update;
insert;
delete;
-- 以上操作都是获取当前读

• 快照读：读取记录的历史版本，而不一定是最新版本

读取时不需要加锁，提高了并发性能

2.2 快照读如何实现

MySQL使用快照读、当前读来实现了MVCC中非阻塞读的功能。

那更具体点，MySQL使怎么实现快照读的呢？

2.2.1 三个隐式字段

• DB_TRX_ID 事务ID

保存：最近修改(修改/插入)事务ID

大小：6byte

• DB_ROLL_PTR 回滚指针

保存：指向这条记录的上一个版本（存储于rollback segment里）

大小：7byte

• DB_ROW_ID 隐藏主键

保存：如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引

大小：6byte

2.2.2 undo日志概念

undo log分两种：

• insert undo log

事务插入新纪录时，产生的undo log，回滚时需要，事务提交后可以被丢弃

• update undo log

事务删除、修改记录时，产生的undo log，回滚时需要，快照读时也需要，所以不能随便删除

只有快照读或事务回滚时不需要该日志时， update undo才会被purge线程同一清除。

拓展1：怎么区分是否需要该日志

首先，当更新或删除一个记录时，旧记录实际上不会被立刻删除，而是将记录的deleted_bit字段置为true，这么做主要是为了实现快照读。

其次：一直保存老的记录，肯定会浪费磁盘空间，所以Innodb有专门的purge线程来清理deleted_bit为true的字段。

但是为了不影响快照读，所以purge线程需要维护一个read view记录系统中最老活跃事务。如果一条记录的deleted_bit字段为true，并且该记录的DB_TRX_ID相对于purge线程的read view是可见的，那么该记录可以被清除而不会影响到快照读。

2.2.3 Read View（读视图）

Read View是事务进行快照读是产生的，ReadView中主要有三个属性：

 trx_list
一个数值列表，用来维护Read View生成时刻系统正活跃的事务ID

 up_limit_id
记录trx_list列表中事务ID最小的ID

 low_limit_id
ReadView生成时刻系统尚未分配的下一个事务ID，
也就是目前已出现过的事务ID的最大值+1

由于ReadView中记录了当前事务ID，所以我们用Read View来做可见性判断，通过比较undo log记录中DB_TRX_ID与ReadView，来判断该记录是否对当前事务可见。

2.2.4 执行事务时undo log分析

undo log实际上就是存在rollback segment中旧记录链

假设一个表Person中只有一个字段：name

**步骤一：**事务0，插入一条新记录，则记录如下

**步骤二：**事务1，修改该记录的name为B

1. 对该记录加排他锁
2. 将该记录拷贝到undo log中，作为旧纪录
3. 修改name为B，将事务ID改为当前事务ID；让回滚指针执行undo log中的旧记录
4. 提交事务，释放锁
   (红色代表日志)

2.2.5 Innodb如何进行当前读

逻辑

1. 每个事务都有维护了一个ReadView，进行快照读时，用记录的DB_TRX_ID与ReadView比较
2. 如果比较不符合可见性，那就通过DB_ROLL_PTR回滚指针去取出undo Log中的记录DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起）
3. 直到找到满足特定条件的DB_TRX_ID，这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本

DB_TRX_ID与ReadView比较逻辑

首先比较DB_TRX_ID < up_limit_id, 如果小于，则当前事务能看到DB_TRX_ID 所在的记录，如果大于等于进入下一个判断

接下来判断 DB_TRX_ID 大于等于low_limit_id , 如果大于等于则代表DB_TRX_ID 所在的记录在Read View生成后才出现的，那对当前事务肯定不可见，如果小于则进入下一个判断

判断DB_TRX_ID 是否在活跃事务之中，trx_list.contains(DB_TRX_ID)，如果在，则代表我Read View生成时刻，你这个事务还在活跃，还没有Commit，你修改的数据，我当前事务也是看不见的；如果不在，则说明，你这个事务在Read View生成之前就已经Commit了，你修改的结果，我当前事务是能看见的

3. 相关问题

RC与RR快照读的有什么不同

• RR级别下，快照读生成Read View时，Read View会记录此时所有其他活动事务的快照，这些事务的修改对于当前事务都是不可见的。而早于Read View创建的事务所做的修改均是可见

• RC级别下的，事务中，每次快照读都会新生成一个快照和Read View, 这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

4. 总结

MVCC在Innodb中，表现的形式是快照读，快照读是以undo log + ReadView + 两个隐藏字段 实现的。

5 参考

MVCC多版本并发控制