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

Posted 2021-04-04 京东科技开发者

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了我身边的高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，分别来修改此数据

时间T	trx_id 200	trx_id 300
T1	开始事务	开始事务
T2	更改名字为A
T3	更改名字为B
T4	提交事务	更改名字为C
T6		提交事务

所以此时的版本链如下

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

第一条数据是小杰，事务ID为100
事务ID为200的事务将名称从小杰改为了A
事务ID为200的事务将名称从A又改为了B
事务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

时间	事务100	事务200	事务300	事务400
T1	A
T2	B
T3		C
T4			读
T5	提交
T6			D
T7				读
T8		E
T9		提交
T10			读

读已提交（RC）与MVCC

一个事务提交之后，它做的变更才会被其他事务看到

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

当T1时刻时，事务100修改名字为A
当T2时刻时，事务100修改名字为B
当T3时刻时，事务200修改名字为C
当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前提交了，此数据可以被读到。所以读取的数据就是小杰。

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

当T5时刻时，事务100提交
当T6时刻时，事务300将名字改为D
当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。

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