MVCC多版本并发控制

MySQL的逻辑架构

redo log日志

redo log（重做日志）：redo log是InnoDB存储引擎层的日志，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。

在一条更新语句进行执行的时候，InnoDB引擎会把更新记录写到redo log日志中，然后更新内存，此时算是语句执行完了，然后在空闲的时候或者是按照设定的更新策略将redo log中的内容更新到磁盘中，这里涉及到WAL即Write Ahead logging技术，它的关键点是先写日志，再写磁盘。

有了redo log日志，那么在数据库进行异常重启的时候，可以根据redo log日志进行恢复，也就达到了crash-safe。

redo log日志的大小是固定的，即记录满了以后就从头循环写。

作用：确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

binlog 日志

binlog（归档日志）：是MySQL Server层记录的日志，是以二进制的形式记录的是这个语句的原始逻辑，依靠binlog是没有crash-safe能力的。

两者都是记录了某些操作的日志(不是所有)自然有些重复（但两者记录的格式不同）。

作用：用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。 用于数据库的基于时间点的还原。

redo log和binlog区别

• redo log是属于innoDB层面，binlog属于MySQL Server层面的，这样在数据库用别的存储引擎时可以达到一致性的要求。
• redo log是物理日志，记录该数据页更新的内容；binlog是逻辑日志，记录的是这个更新语句的原始逻辑
• redo log是循环写，日志空间大小固定；binlog是追加写，是指一份写到一定大小的时候会更换下一个文件，不会覆盖。
• binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。

undo log(回滚日志)

作用：保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。

undo log提供两种功能：

• 事务回滚
• MVCC

undo log主要分为两种：

• insert undo log：代表事务在insert新记录时产生的undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃。
• update undo log：事务在进行update或delete时产生的undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快照读或事务回滚不涉及该日志时，对应的日志才会被purge线程统一清除。

purge

• 从前面的分析可以看出，为了实现InnoDB的MVCC机制，更新或者删除操作都只是设置一下老记录的deleted_bit，并不真正将过时的记录删除。
• 为了节省磁盘空间，InnoDB有专门的purge线程来清理deleted_bit为true的记录。为了不影响MVCC的正常工作，purge线程自己也维护了一个read view（这个read view相当于系统中最老活跃事务的read view）;如果某个记录的deleted_bit为true，并且DB_TRX_ID相对于purge线程的read view可见，那么这条记录一定是可以被安全清除的。

MVCC是什么

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制。MVCC是一种并发控制的方法，一般在数据库管理系统中，实现对数据库的并发访问，在编程语言中实现事务内存。

在学习MVCC多版本并发控制之前，我们必须先了解一下，什么是MySQL InnoDB下的当前读和快照读？

什么是当前读和快照读

当前读

select lock in share mode(共享锁), select for update ; update, insert,delete(排他锁)这些操作都是一种当前读。

当前读就是读取记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。

快照读

• 不加锁的操作(select)就是快照读，即不加锁的非阻塞读；
• 快照读的前提是隔离级别不是串行级别，串行级别下的快照读会退化成当前读；
• 即MVCC,可以认为MVCC是行锁的一个变种，但它在很多情况下，避免了加锁操作，降低了开销；
• 快照读的实现是基于多版本并发控制，既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本；

MVCC作用

数据库并发场景有三种，分别为：

• 读-读：不存在任何问题，也不需要并发控制
• 读-写：有线程安全问题，可能会造成事务隔离性问题，可能遇到脏读，幻读，不可重复读
• 写-写：有线程安全问题，可能会存在更新丢失问题，比如第一类更新丢失，第二类更新丢失

MVCC作用：解决读-写冲突的无锁并发控制，这里的读是快照读。

• 在并发读-写数据库时，可以做到在读操作时不用阻塞写操作，写操作也不用阻塞读操作，提高了数据库并发读写的性能
• 同时还可以解决脏读，幻读，不可重复读等事务隔离问题，但不能解决更新丢失问题

MVCC组合：

• MVCC + 悲观锁：MVCC解决读写冲突，悲观锁解决写写冲突
• MVCC + 乐观锁：MVCC解决读写冲突，乐观锁解决写写冲突

MVCC的实现原理

MVCC的目的就是多版本并发控制，在数据库中的实现，就是为了解决读写冲突，它的实现原理主要是依赖记录中的 3个隐式字段，undo日志 ，Read View 来实现的。

隐式字段

每行记录除了我们自定义的字段外，还有数据库隐式定义的DB_ROW_ID，DB_TRX_ID，DB_ROLL_PTR等字段。

• DB_ROW_ID：6byte，隐含的自增ID（隐藏主键），如果数据表没有主键，InnoDB会自动以DB_ROW_ID产生一个聚簇索引
• DB_TRX_ID：6byte，最近修改(修改/插入)事务ID：记录创建这条记录/最后一次修改该记录的事务ID
• DB_ROLL_PTR：7byte，回滚指针，指向这条记录的上一个版本（存储于rollback segment【回滚段】里）

如上图，DB_ROW_ID是数据库默认为该行记录生成的唯一隐式主键，DB_TRX_ID是当前操作该记录的事务ID，而DB_ROLL_PTR是一个回滚指针，用于配合undo日志，指向上一个旧版本。

行的更新过程

对MVCC有帮助的实质是update undo log，它的执行流程如下：

1、比如有个事务向person表插入了一条新记录，记录如下，name为Jerry, age为24岁，隐式主键是1，事务ID和回滚指针，我们假设为NULL

2、现在来了一个事务1对该记录的name做出了修改，改为Tom

• 在事务1修改该行(记录)数据时，数据库会先对该行加排他锁
• 然后把该行数据拷贝到undo log中，作为旧记录，即在undo log中有当前行的拷贝副本
• 拷贝完毕后，修改该行name为Tom，并且修改隐藏字段的事务ID为当前事务1的ID，我们默认从1开始，之后递增，回滚指针指向拷贝到undo log的副本记录，即表示我的上一个版本就是它
• 事务提交后，释放锁

3、又来了个事务2修改person表的同一个记录，将age修改为30岁

• 在事务2修改该行数据时，数据库也先为该行加锁
• 然后把该行数据拷贝到undo log中，作为旧记录，发现该行记录已经有undo log了，那么最新的旧数据作为链表的表头，插在该行记录的undo log最前面
• 修改该行age为30岁，并且修改隐藏字段的事务ID为当前事务2的ID, 那就是2，回滚指针指向刚刚拷贝到undo log的副本记录
• 事务提交，释放锁

从上面，我们就可以看出，不同事务或者相同事务的对同一记录的修改，会导致该记录的undo log成为一条记录版本线性表，即链表，undo log的链首就是最新的旧记录，链尾就是最早的旧记录（当然就像之前说的该undo log的节点可能是会purge线程清除掉，像图中的第一条insert undo log，其实在事务提交之后可能就被删除丢失了，不过这里为了演示，所以还放在这里）

Read View(读视图)

Read View就是事务进行快照读操作的时候生产的读视图(Read View)，在该事务执行的快照读的那一刻，会生成数据库系统当前的一个快照，记录并维护系统当前活跃事务的ID(当每个事务开启时，都会被分配一个ID, 这个ID是递增的，所以最新的事务，ID值越大)。

Read View的组成：所有未提交事务id数组【活跃事务】和已创建的最大事务id组成。

作用：用来做可见性判断的, 即当我们某个事务执行快照读的时候，对该记录创建一个Read View读视图，把它比作条件用来判断当前事务能够看到哪个版本的数据，即可能是当前最新的数据，也有可能是该行记录的undo log里面的某个版本的数据。

怎么判断当前事务能看到哪个版本的数据

1、将当前事务的事务id取出来

2、假设readview:[100,200],300 表示当前系统有两个活跃事务id分别为100,200以及已创建的最大事务300

活跃事务中id最小的和已创建的最大事务，可以划分为3部分：

• 小于100的是已经提交过的事务
• 100-300的是活跃事务或者已提交事务
• 300以上的是未开始的事务

3、版本链对比规则

• 如果当前事务id落在小于100的区域上，表示这个版本是已经提交的事务生成的，这个数据是可见的
• 如果落在大于300的区域上，表示这个版本是由将来启动的事务生成的，肯定是不可见的
• 如果落在100-300的区域上，又有两种情况
  • 若当期事务id在数组中，表示这个版本是由还没提交的事务生成的，不可见
  • 若当前事务id不在数组中，表示这个版本是已经提交了的事务生成的，可见

MVCC 整体流程

整体的流程是怎么样的呢？我们可以模拟一下：

1、当事务2对某行数据执行了快照读，数据库为该行数据生成一个Read View读视图，假设当前事务ID为2，此时还有事务1和事务3在活跃中，事务4在事务2快照读前一刻提交更新了，所以Read View记录了系统当前活跃事务1，3的ID，维护在一个数组上。

此时的readview:[1,3],4，Read View如下图：

2、只有事务4修改过该行记录，并在事务2执行快照读前，就提交了事务，所以该行当前数据的undo log如下图所示；
我们的事务2在快照读该行记录的时候，就会拿该行记录的DB_TRX_ID【该行记录的事务id】 4去跟min_id,max_id和活跃事务ID列表进行比较，判断当前事务2能看到该记录的版本是哪个。

• 事务id=4，不小于min_id，所以不符合条件
• 事务id=4，没有大于max_id，所以不符合条件
• 事务id=4，小于等于max_id，符合条件
  • 判断4是否处于活跃事务列表中, 最后发现事务ID为4的事务不在当前活跃事务列表中, 符合可见性条件

所以事务4修改后提交的最新结果对事务2快照读时是可见的，所以事务2能读到的最新数据记录是事务4所提交的版本，而事务4提交的版本也是全局角度上最新的版本。

RC,RR级别下的InnoDB快照读有什么不同？

读已提交(RC)：RC隔离级别下，每个快照读都会生成并获取最新的Read View,每次都读取undo log中最近的版本，因此两次对同一字段的读可能读到不同的数据（幻读），但能保证每次都读到最新的数据。

可重复读(RR)：在RR隔离级别下，则是同一个事务中的第一个快照读才会创建Read View, 之后的快照读获取的都是同一个Read View。每次都读取undo log指定的版本，这样保证不会产生幻读，但可能读不到最新的数据。

参考：

• Mysql中的MVCC（多版本并发控制）