诚意满满之MySQL实现事务隔离的秘诀：锁与MVCC

​

如果对事务没有太多理解，可以看前面三篇：

诚意满满之讲透事务

诚意满满之讲透事务隔离级别

诚意满满之MySQL如何实现原子性、持久性

不看前三篇也没有关系，知识点是独立的。

MySQL的四个事务隔离级别：读未提交、读已提交、可重复读、串行读。其中，读未提交即是不加任何限制，串行读则可以理解为单线程更新数据，比较简单，没有太多的探讨价值。

本文立足于读已提交和可重复读这两个痛点，以锁和MVCC为抓手，对齐读已提交和可重复读两个事务隔离级别的解决思路，通过分析MySQL的打法，沉淀出一套通用的方法论，进而在本系列内形成闭环，为八股文赋能。

咳咳，一不小心暴露了职业基本功.....

​

MVCC

MVCC，全称Multi-Version Concurrency Control，即多版本并发控制,用以对数据库实现并发访问。

你说并发访问不就是加锁，加锁就加锁，咋还搞这么多花里胡哨的。

在了解为什么会有MVCC之前，我们先讲两个概念：

什么是当前读和快照读？

当前读：

像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，为什么叫当前读？就是它读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。说白了，这其实悲观锁的一种实现

快照读

既然当前读是悲观锁的一种实现，相对的，快照读是乐观锁的一种实现。快照读的实现是基于多版本并发控制，即MVCC，在很多情况下，避免了加锁操作，降低了开销；既然是基于多版本，即快照读可能读到的并不一定是数据的最新版本，而有可能是之前的历史版本。

就跟拍照一样，快照读每来一个事务就按下快门，并基于此时刻的数据进行读取。

快照读的前提是事务隔离级别不是串行级别，串行级别下的快照读会退化成当前读。同样的，作为快照读的思想理论指导，MVCC一般也只放在读已提交、可重复读这两个级别下讨论。

至于读未提交，读未提交表示：不好意思，我没有锁的概念。

MVCC的实现原理

MVCC的目的就是多版本并发控制，在MySQL的innodb的实现中，它的实现原理主要是依赖记录中的 3个隐式字段、undo log 和Read View 。

我们先分别说下这三个东西：

三个隐藏字段是之前提到的：

• DB_TRX_ID：最后对该行进行插入或修改的事务ID
• DB_ROLL_PTR：回滚指针，指向该数据的上一个版本，本质上就是指向undo log的指针。
• DB_ROW_ID，隐藏主键。

undolog，回滚日志，在之前的有提到，回滚日志是一条链，由历史数据版本组成。

ReadView（读视图）

什么是ReadView？

前面我们说了，快照读就跟拍照一样，每来一个事务就按下快门。ReadView可以理解为是当前存活事务的相片集。当事务执行快照读的时候（记住这个前提，这是readview的生成时机） ，系统就会维护一个当前活跃事务的id池用来做可见性判断，这个id池就是ReadView。

Read View遵循一个可见性算法，主要是将要被修改的数据的最新记录中的DB_TRX_ID（即当前事务ID）取出来，与系统当前其他活跃事务的ID去对比（由Read View维护），如果DB_TRX_ID跟Read View的属性做了某些比较，不符合可见性，那就通过DB_ROLL_PTR回滚指针去取出Undo Log中的DB_TRX_ID再比较，即遍历链表的DB_TRX_ID（从链首到链尾，即从最近的一次修改查起），直到找到满足特定条件的DB_TRX_ID, 那么这个DB_TRX_ID所在的旧记录就是当前事务能看见的最新老版本。

如何做可见性判断的呢？

我们把ReadView简单理解为有三个全局属性：

• trx_list：一个由事务id组成的列表，用来维护ReadView生成时刻系统活跃的事务ID
• up_limit_id:记录trx_list中最小的事务id。是的，是最小的事务id，这里up的意思应该是最久的意思，即存活时间最久的事务id（事务id都是从小到大递增，id最小说明事务越早创建）。
• low_limit_id:存活时间最短的事务id

当事务读取记录时，获取记录上的DB_TRX_ID,进行以下比较：

当DB_TRX_ID=当前事务id，return true，表示可以读取，反之进入2

当DB_TRX_ID<up_limit_id,说明当前记录是更早存在的，当前事务能看到DB_TRX_ID 所在的记录，反之进入3

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

如果DB_TRX_ID在trx_list里，则代表readview生成时，DB_TRX_ID所代表的事务还在活跃（即此事务还没提交），那么对当前事务肯定不可见。如果DB_TRX_ID不在trx_list里，则说明，DB_TRX_ID这个事务在Read View生成之前就已经Commit了，当前事务是肯定可见的。

用下图来说明，此时正在活跃的事务为[4，6，8]，up_limit_id=4,low_limit_id=8。当前事务准备读取DB_TRX_ID为3、6、7、9的记录。

​

读取DB_TRX_ID=3时，由于3 < up_limit_id，可见

读取DB_TRX_ID=6时，由于6是正在活跃的事务（还没提交），因此不可见

读取DB_TRX_ID=7时，由于7 < low_limit_id，且不在活跃事务中，可见

读取DB_TRX_ID=9时，由于9 > low_limit_id，说明9是未来事务创建的，不可见。

知道了ReadView的可见性判断条件之后，这里抛出一个问题：读已提交和可重复读是怎么用ReadView解决的？

ReadView如何解决读已提交和可重复读

ReadView如何解决读已提交和可重复读，区别在于ReadView的生成。

• 在可重复读级别下的某个事务的对某条记录的第一次快照读会创建一个快照及Read View, 将当前系统活跃的其他事务记录起来，这些事务的修改对于当前事务都是不可见的，而早于Read View创建的事务所做的修改均是可见。此后在调用快照读的时候，还是使用的是同一个Read View。
• 而在读已提交级别下，事务中每次快照读都会新生成一个快照和Read View, 因此在两个ReadView生成中间的修改在后一个ReadView是可见的，这就是我们在RC级别下的事务中可以看到别的事务提交的更新的原因

总结：

• 快照读与当前读，前者是乐观的并发控制思想，后者是悲观的体现。

• MVCC，多版本并发控制，是快照读的一种实现

  • MVCC实现事务隔离的三个关键：隐藏字段、undolog、ReadView
  • ReadView包含三个属性：trx_list、up_limit_id、low_limit_id。根据这三个条件与隐藏字段DB_TRX_ID的对比可判断事务对当前数据版本是否可见，不可见则沿着unlog寻找。
  • 在可重复读隔离级别下，ReadView只会在一开始快照读时生成；在读已提交隔离级别下，ReadView会在每次读取时生成。       

诶，等等，锁呢？

咳咳，留到下一篇

​