Mysql的mvcc版本事务控制

一、什么是MVCC

多版本并发控制，MVCC是通过数据行的多个版本管理来实现数据库的并发控制。这使得在InnoDB的事务隔离级别下执行一致性读操作有了保证。换言之，就是为了查询一些正在被另一个事务

更新的行，并且可以看到它们被更新之前的值，这样在查询时就不用等待另一个事务释放锁。

二、快照读与当前读

● MVCC为了提高数据库性能，更好的处理读-写冲突，即使有读写冲突时，也能做到不加锁，非阻塞并发读，这个读就指快照读，而非当前读。当前读是悲观锁，而MVCC本质是乐观锁

1.快照读

● 又叫一致性读，读取的是快照数据，不加锁的简单select都属于快照读，即不加锁的非阻塞读

● 快照读可能读到的并不一定是数据的最新版本，有可能是之前的历史版本

2.当前读

● 当前读读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。加锁的select，或者对数据进行增删改都会进行当前读

三、MVCC三剑客：隐藏字段、UndoLog版本链、ReadView规则

1.隐藏字段

● 对于InnoDB存储引擎的表来说，它的聚簇索引记录中都包含两个必要的隐藏列：

○ trx_id：每次一个事务对某条聚簇索引记录进行改动时，都会把该事务的事务id赋值给trx_id隐藏列。

○ roll_pointer：每次对某条聚簇索引记录进行改动时，都会把旧的版本写入到undo日志中，然后这个隐藏列就相当于一个指针，可以通过它来找到该记录修改前的信息

● insert undo只在事务回滚时起作用，当事务提交后，该类型的undo日志就没用了，它占用的Undo Log也会被系统回收

● 每次对记录进行改动，都会记录一条undo日志，每条undo日志也都要一个roll_pointer属性，可以将这些undo日志都连起来，串成一个链表：

● 对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，称之为版本链，版本链头 节点就是当前记录最新的值。每个版本中还包含生成该版本时对应的事务id

2.UndoLog日志

● undolog是事务原子性的保证。在事务中更新数据的前置操作其实是要先写入一个undolog

3.MVCC实现原理之ReadView

● MCVV实现依赖于：隐藏字段、UndoLog、ReadView

1.什么是ReadView

● 多个事务对同一记录更新会产生多个历史快照，历史快照保存在UndoLog里，ReadView帮我们解决行的可见性问题，解决哪个版本事务当前可见

● ReadView就是事务在使用MVCC机制进行行快照读操作时产生的读视图。事务启动时,会生成数据库系统当前一个快照,InnoDB为每个事务构造了一个数组，用来记录和维护活跃事务ID

2.ReadView中包含4个比较重要的内容

● creator_trx_id：创建这个Read View的事务ID。只有增删改才会

● trx_ids：表示在生成Read View时当前系统中活跃的读写事务的ID列表

● up_limit_id：活跃的事务中最小的事务ID

● low_limit_id：表示生成ReadView时系统应该分配给下一个事务ID的值。它是系统最大的事务ID值，区别于正在活跃的事务

3.ReadView的规则

● 如果被访问版本的trx_id属性值与ReadView中的creator_trx_id值相同，意味着当前事务在访问它自己修改过的记录，所以该版本可以被当前事务访问

● 如果被访问版本的trx_id属性值小于ReadView中的low_limit_id值，表面生成该版本的事务在当前事务生成ReadView前已经提交，所以该版本可以被当前事务访问

● 如果被访问版本的trx_id属性值大于ReadView中的up_limit_id值，表面生成该版本的事务在当前事务生成ReadView后才开启，所以不可被当前事务访问

● 如果被访问版本的trx_id属性值在ReadView的up_limit_id和low_limit_id之间，那就要判断一下trx_id属性值是不是在trx_ids列表中：

○ 如果在，说明创建ReadView时生成该版本的事务还是活跃的，该版本不可被访问

○ 如果不在，说明创建ReadView时生成该版本的事务已被提交，该版本可以被访问

4.MVCC整体操作流程

1）首先获取事务自己的版本号，也就是事务ID

2）获取ReadView

3）查询得到的数据，然后与ReadView中的事务版本号进行比较

4）如果不符合ReadView规则，就需要从UndoLog中获取历史快照

5）最后返回符合规则的数据

● 如果某个版本的数据对当前事务不可见的话，就顺着版本链找到下一个版本的数据，继续按照ReadView的规则判断可见性，知道版本链最后一个版本。如果也不可见，也就是该条记录 对该事务完全不可见，查询结果就不包含该记录

● InnoDB中，MVCC是通过UndoLog+ReadView进行数据读取UndoLog保存了历史快照，而ReadView规则则帮助我们判断当前版本的数据是否可见

● 当隔离级别为可重复读时，一个事务只在第一次select的时候获取一次ReadView，后面的所有的select都会复用这个ReadView

四、总结

1.MVCC只在READ COMMITTED、REPEATABLE READ这两种隔离级别的事务在执行快照读操作时访问记录的版本链过程。

2.核心点在于ReadView的原理，READ COMMITTED、REPEATABLE READ这两种隔离级别生成ReadView的时机不同：

● READ COMMITTED在每一次进行普通SELECT操作前都会生成一个ReadView

● REPEATABLE READ只在第一次进行普通SELECT操作前生成一个ReadView，之后的查询操作都用这个ReadView

3.通过MVCC可以解决：

● 读写之间阻塞的问题。通过MVCC可以让读写互相不阻塞，提升事务并发处理的能力

● 降低了死锁的概率：因为MCVV采用乐观锁的方式，读取数据时并不加锁，对于写操作，也只锁定必要的行

● 解决快照读的问题。当我们查询数据库在某个时间点的快照是，只能看到这个时间点之前事务提交更新的结果，而不能看到这个时间点之后事务提交的结果