我身边的高T，问了Java面试者这样的问题......

你们好，我是来自JDL京东物流技术发展部邢焕杰， 今天来分享一个京东面试真题，这也是我前阵子听我工位旁边高T（高，实在是高）面试候选人的时候问的一个问题，他问，你能说说 MySQL的事务吗？MVCC有了解吗？话很少说，本文就深度解析一下MySQL事务及MVCC的实现原理。

事务定义及四大特性

• 事务是什么？
• 事务的四大特性（简称ACID）：
• 原子性（Atomicity）：一个事务是一个不可分割的工做单位，事务中包括的操做要么都作，要么都不作。
• 一致性（Consistency）：事务必须是使数据库从一个一致性状态变到另外一个一致性状态。一致性与原子性是密切相关的。
• 隔离性（Isolation）：一个事务的执行不能被其余事务干扰。即一个事务内部的操做及使用的数据对并发的其余事务是隔离的，并发执行的各个事务之间不能互相干扰.
• 持久性（Durability）：指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的,接下来的其余操做或故障不该该对其有任何影响。

事务中常见问题

• 脏读（dirty read）：就是一个A事务即使没有提交，它对数据的修改也能够被其余事务B事务看到，B事务读到了A事务还未提交的数据，这个数据有多是错的，有可能A不想提交这个数据，这只是A事务修改数据过程当中的一个中间数据，可是被B事务读到了，这种行为被称做脏读，这个数据被称为脏数据
• 不可重复读（non-repeatable read）：在A事务内，屡次读取同一个数据，可是读取的过程当中，B事务对这个数据进行了修改，致使此数据变化了，那么A事务再次读取的时候，数据就和第一次读取的时候不同了，这就叫作不可重复读
• 幻读（phantom read）：A事务屡次查询数据库，结果发现查询的数据条数不同，A事务屡次查询的间隔中，B事务又写入了一些符合查询条件的多条数据（这里的写入能够是update，insert，delete），A事务再查的话，就像发生了幻觉同样，怎么忽然改变了这么多，这种现象这就叫作幻读

隔离级别——产生问题的缘由

多个事务互相影响，并无隔离好，就是咱们刚才提到的事务的四大特性中的 隔离性（Isolation） 出现了问题 事务的隔离级别并无设置好，下面咱们来看下事务究竟有哪几种隔离级别

• 隔离级别
• 读未提交（read uncommitted RU）： 一个事务还没提交时，它作的变动就能被别的事务看到
• 读提交（read committed RC）： 一个事务提交以后，它作的变动才会被其余事务看到。
• 可重复读（repeatable read RR）： 一个事务执行过程当中看到的数据，老是跟这个事务在启动时看到的数据是一致的。固然在可重复读隔离级别下，未提交变动对其余事务也是不可见的。
• 串行化（serializable ）： 顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。

咱们来看个例子，更加直观的了解这四种隔离级别和上述问题脏读，不可重复读，幻读的关系

下面咱们讨论下当事务处于不一样隔离级别状况时，V1,V2,V3分别是什么不一样的值吧

• 读未提交 (RU)： A事务能够读取到B事务修改的值，即使B事务没有提交。因此V1就是200
• V1 : 200
• V2 : 200
• V3 : 200
• 读提交（RC）： 当B事务没有提交的时候，A事务不能够看到B事务修改的值，只有提交之后才能够看到
• V1 : 100
• V2 : 200
• V3 : 200
• 可重复读（RR）： A事务屡次读取数据，数据总和第一次读取的同样，
• V1 : 100
• V2 : 100
• V3 : 200
• 串行化（S）： 事务A在执行的时候，事务B会被锁住，等事务A执行结束后，事务B才能够继续执行
• V1 : 100
• V2 : 100
• V3 : 200

MVCC原理

MVCC（Multi-Version Concurrency Control）多版本并发控制，是数据库控制并发访问的一种手段。

• 特别要注意MVCC只在 读已提交(RC) 和 可重复度（RR） 这两种事务隔离级别下才有效
• 是 数据库引擎（InnoDB） 层面实现的，用来处理读写冲突的手段（不用加锁），提升访问性能

MVCC是怎么实现的呢？它靠的就是版本链和一致性视图

1. 版本链

• 版本链是一条链表，连接的是每条数据曾经的修改记录

那么这个版本链又是如何造成的呢，每条数据又是靠什么连接起来的呢？

实际上是这样的，对于InnoDB存储引擎的表来讲，它的聚簇索引记录包含两个隐藏字段

• trx_id: 存储修改此数据的事务id，只有这个事务操做了某些表的数据后当更改操做发生的时候（update,delete,insert），才会分配惟一的事务id,而且此事务id是递增的
• roll_pointer: 指针，指向上一次修改的记录
• row_id(非必须): 当有主键或者有不容许为null的unique键时，不包含此字段

假如说当前数据库有一条这样的数据，假设是事务ID为100的事务插入的这条数据，那么此条数据的结构以下

后来，事务200，事务300，分别来修改此数据

因此此时的版本链以下

咱们每更改一次数据，就会插入一条undo日志，而且记录的roll_pointer指针会指向上一条记录，如图所示

1. 第一条数据是小杰，事务ID为100
2. 事务ID为200的事务将名称从小杰改成了A
3. 事务ID为200的事务将名称从A又改成了B
4. 事务ID为300的事务将名称从B又改成了C

因此串成的链表就是 C -> B -> A -> 小杰 （从最新的数据到最老的数据）

2. 一致性视图（ReadView）

须要判断版本链中的哪一个版本是是当前事务可见的，所以有了一致性视图的概念。其中有四个属性比较重要

• m_ids: 在生成ReadView时，当前活跃的读写事务的事务id列表
• min_trx_id: m_ids的最小值
• max_trx_id: m_ids的最大值+1
• creator_trx_id: 生成该事务的事务id，单纯开启事务是没有事务id的，默认为0，creator_trx_id是0。

版本链中的当前版本是否能够被当前事务可见的要根据这四个属性按照如下几种状况来判断

• 当 trx_id = creator_trx_id 时:当前事务能够看见本身所修改的数据， 可见，
• 当 trx_id < min_trx_id 时   : 生成此数据的事务已经在生成readView前提交了， 可见
• 当  trx_id >= max_trx_id 时   :代表生成该数据的事务是在生成ReadView后才开启的， 不可见
• 当  min_trx_id <= trx_id < max_trx_id 时
• trx_id 在 m_ids 列表里面 ：生成ReadView时，活跃事务还未提交，不可见
• trx_id 不在 m_ids 列表里面 ：事务在生成readView前已经提交了，可见

若是某个版本数据对当前事务不可见，那么则要顺着版本链继续向前寻找下个版本，继续这样判断，以此类推。

注：RR和RC生成一致性视图的时机不同 （这也是两种隔离级别实现的主要区别）

• 读提交（read committed RC） 是在每一次select的时候生成ReadView的
• 可重复读（repeatable read RR）是在第一次select的时候生成ReadView的

下面我们一块儿来举个例子实战一下。

RR与RC和MVCC的例子实战

假如说，咱们有多个事务以下执行，咱们经过这个例子来分析当数据库隔离级别为RC和RR的状况下，当时读数据的一致性视图和版本链，也就是MVCC，分别是怎么样的。

• 假设数据库中有一条初始数据  姓名是java小杰要加油，id是1 （id,姓名,trx_id,roll_point），插入此数据的事务id是1
• 尤为要指出的是，只有这个事务操做了某些表的数据后当更改操做发生的时候（update,delete,insert），才会分配惟一的事务id,而且此事务id是递增的，单纯开启事务是没有事务id的，默认为0，creator_trx_id是0。
• 如下例子中的A,B,C的意思是将姓名更改成A,B,C 读也是读取当前时刻的姓名,默认全都开启事务,而且此事务都经历过某些操做产生了事务id

读已提交（RC）与MVCC

• 一个事务提交以后，它作的变动才会被其余事务看到

每次读的时候，ReadView(一致性视图)都会从新生成

1. 当T1时刻时，事务100修更名字为A
2. 当T2时刻时，事务100修更名字为B
3. 当T3时刻时，事务200修更名字为C
4. 当T4时刻时，事务300开始读取名字

• 此时这条数据的版本链以下

同颜色表明是同一事务内的操做

• 来咱们静下心来好好分析一下此时T4时刻事务300要读了，究竟会读到什么数据？

当前最近的一条数据是，C，事务200修改的，还记得咱们前文说的一致性视图的几个属性吗，和按照什么规则判断这个数据能不能被当前事务读。咱们就分析这个例子。

此时  （生成一致性视图ReadView）

• m_ids 是[100,200]： 当前活跃的读写事务的事务id列表
• min_trx_id 是 100：  m_ids的最小值
• max_trx_id 是 201： m_ids的最大值+1

当前数据的trx_id(事务id)是 200，符合min_trx_id<=trx_id<max_trx_id 此时须要判断 trx_id 是否在m_ids活跃事务列表里面，一看，活跃事务列表里面是【100，200】，只有两个事务活跃，而此时的trx_id是200，则trx_id在活跃事务列表里面，活跃事务列表表明还未提交的事务，因此该版本数据不可见，就要根据roll_point指针指向上一个版本，继续这样的判断，上一个版本事务id是100，数据是B，发现100也在活跃事务列表里面，因此不可见，继续找到上个版本，事务是100，数据是A，发现是一样的状况，继续找到上个版本，发现事务是1，数据是小杰，1小于100，trx_id<min_trx_id，表明生成这个数据的事务已经在生成ReadView前提交了，此数据能够被读到。因此读取的数据就是小杰。

分析完第一个读，咱们继续向下分析

1. 当T5时刻时，事务100提交
2. 当T6时刻时，事务300将名字改成D
3. 当T7时刻时，事务400读取当前数据

• 此时这条数据的版本链以下

此时 （从新生成一致性视图ReadView）

• m_ids 是[200,300]： 当前活跃的读写事务的事务id列表
• min_trx_id 是 200：  m_ids的最小值
• max_trx_id 是 301： m_ids的最大值+1

当前数据事务id是300，数据为D，符合min_trx_id<=trx_id<max_trx_id 此时须要判断数据是否在活跃事务列表里，300在这里面，因此就是还未提交的事务就是不可见，因此就去查看上个版本的数据，上个版本事务id是200，数据是C，也在活跃事务列表里面，也不可见，继续向上个版本找，上个版本事务id是100，数据是B，100小于min_trx_id，就表明，表明生成这个数据的事务已经在生成ReadView前提交了，此数据可见，因此读取出来的数据就是B。

分析完第二个读，咱们继续向下分析

1. 当T8时刻时，事务200将名字改成E
2. 当T9时刻时，事务200提交
3. 当T10时刻时，事务300读取当前数据

• 此时这条数据的版本链以下

此时 （从新生成一致性视图ReadView）

• m_ids 是[300]： 当前活跃的读写事务的事务id列表
• min_trx_id 是 300：  m_ids的最小值
• max_trx_id 是 301： m_ids的最大值+1

当前事务id是200，200<min_trx_id ,表明生成这个数据的事务已经在生成ReadView前提交了，此数据可见，因此读出的数据就是E。

当隔离级别是读已提交RC的状况下，每次读都会从新生成 一致性视图（ReadView）

• T4时刻 事务300读取到的数据是小杰
• T7时刻 事务400读取到的数据是B
• T10时刻 事务300读取到的数据是E

可重复读（RR）与MVCC

• 一个事务执行过程当中看到的数据，老是跟这个事务在启动时看到的数据是一致的

因此对于事务300来说，它分别在T4和T10的时候，读取数据，可是它的一致性视图， 用的永远都是第一次读取时的视图，就是T3时刻产生的一致性视图

RR和RC的版本链是同样的，可是判断当前数据可见与否用到的一致性视图不同

在此可重复读RR隔离级别下，

1. T4时刻时事务300第一次读时的分析和结果与RC都同样，能够见上文分析与结果
2. T7时刻时事务400第一次读时的分析和结果与RC都同样，能够见上文分析与结果
3. T10时刻时事务300第二次读时的一致性视图和第一次读时的同样，因此此时到底读取到什么数据就要从新分析了

此时  （用的是第一次读时生成的一致性视图ReadView）

• m_ids 是[100,200]： 当前活跃的读写事务的事务id列表
• min_trx_id 是 100：  m_ids的最小值
• max_trx_id 是 201： m_ids的最大值+1

此时的版本链是

当前数据的事务id是200，数据是E，在当前事务活跃列表里面，因此数据不可见，根据回滚指针找到上个版本，发现事务id是300，当前事务也是300，可见，因此读取的数据是D

• 咱们能够本身思考下，要是没有事务300这条更改的这条记录，又该怎么继续向下分析呢？

当隔离级别是可重复读RR的状况下，每次读都会用第一次读取数据时生成的一致性视图（ReadView）

• T4时刻 事务300读取到的数据是小杰
• T7时刻 事务400读取到的数据是B
• T10时刻 事务300读取到的数据是D

欢迎点击【京东科技】，了解开发者社区

更多精彩技术实践与独家干货解析

欢迎关注【京东科技开发者】公众号