跟面试官侃半小时MySQL事务隔离性，从基本概念深刻到实现

提到MySQL的事务，我相信对MySQL有了解的同窗都能聊上几句，不管是面试求职，仍是平常开发，MySQL的事务都跟咱们息息相关。

而事务的ACID（即原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability）能够说涵盖了事务的所有知识点，因此，咱们不只要知道ACID是什么，还要了解ACID背后的实现，只有这样，不管在平常开发仍是面试求职，都能无往而不利。

为了你们更好的阅读体验，对ACID的深刻分析将分为上下两篇。

本篇为上篇，主要围绕ACID中的I,也就是“隔离性”展开，从基本概念，到隔离性的实现，最后以一个实战案例进行融会贯通。

嗯，看完你都能理解，那跟面试官侃半小时隔离性就没问题了。

1.事务隔离性的基本概念

1.1 什么是ACID中的Isolation,隔离性

Isolation,隔离性，也有人称之为并发控制（concurrency control）。事务的隔离性要求每一个事务读写的对象对其余事务都是相互隔离的，也就是这个事务提交前，这个事务的修改内容对其余事务都是不可见的。事务的隔离性，主要是解决不一样事物之间的相互读写影响。

所谓的读写影响注意分为三种：

• 脏读：读到了别的事务还没有提交（commit）的变动，别人没提交，我读到了。
• 不可重复读：别的事务提交了变动，被当前事务读到了。而后致使本事务屡次select的结果不同，读到了别的事务提交的内容。
• 幻读：也是读到了别的事务提交的内容，可是跟上面的不一样之处在于，读到了本来不存在的记录。

注意，不可重复读，主要是读到了别的事务update的内容。而幻读，是读到了别的事务insert的内容。

1.2 隔离性的隔离级别

为了解决事务隔离性的问题，数据库通常会有不一样的隔离级别来解决相应的读写影响。

• 读未提交：一个事务B还没提交，它的修改就被别的事务A读到了。
• 读已提交：一个事务B提交后，它的修改被其余事务A看到了。
• 可重复读：一个事物B提交前和提交后，事务A都没法读到事务B的变动。
• 串行化：对同一行记录，当出现不一样事物的读写冲突时，是经过串行化的方式解决的，后一个事务必须等前一个事务完成才能执行。

不一样隔离级别可以解决不一样的隔离性问题。

 

须要注意的是，这是标准事务隔离级别的定义。在MySQL的innodb引擎中，在可重复读级别下，经过mvcc解决了幻读的问题，具体实现咱们后面再讲。

同时，须要注意的是，到目前为止，咱们说的读，都是”快照读”，普通的select。后面咱们还会提到“当前读”，是不同的哦。

2.事务隔离性的实现

要实现事务的隔离性，须要了解两个方面的内容，一个是锁，一个是多版本并发控制（MVCC）。

2.1 事务的行锁

InnoDB中，实现了两种标准的行级锁：

• 共享锁（S Lock），也叫读锁，容许事务读取一行数据。
• 排它锁（X Lock），也叫写锁，容许事务删除或者更新一行数据（注意，这里没有提到插入哦，插入涉及到幻读，能够看文章最后的说明）

普通select语句不会有任何锁，那么如何得到共享锁和排它锁呢？

• Select … lock in share mode语句可以得到共享锁
• Select … for update（特殊的select，用mysql简单实现分布式锁常常用它）、Update、delete语句可以得到排它锁

当一个事务A已经得到了行r的共享锁，那么另外一个事务B能够马上得到行r的共享锁，由于不会改变r的数值，这种叫作锁兼容。

若是这时候有事务C但愿得到行r的排它锁，那么就必须等待事务A和事务B释放行r的共享锁以后，才能得到排它锁，这种叫作锁不兼容。

 

普通的select不会对行上锁，而select…lock in share mode会上共享锁，select…for update会上排它锁。

• 对于普通的select的读取方式，称为”快照读“，也叫”一致性非锁定读“。
• 对于带锁的select读取，或者update tb set a = a+1（读取a的当前值），称为“当前读”，也叫“一致性锁定读”。

若是在update、insert的时候，不能进行select，那么服务的并发访问性能就太差了。所以，咱们平常的查询，都是“快照读”，不会上锁，只有在update\insert\“当前读”的时候，才会上锁。而为了解决“快照读”的并发访问问题，就引入了MVCC。

2.2 多版本并发控制MVCC

若是说上面的行锁是一种悲观锁，那么MVCC就是一种乐观锁的实现方式，并且是一种很经常使用的乐观锁实现方式。

所谓多版本，就是一行记录在数据库中存储了多个版本，每一个版本以事务ID做为版本号。InnoDB 里面每一个事务有一个惟一的事务 ID，是在事务开始的时候向InnoDB的事务系统申请的，而且按照申请顺序严格递增的。假如一行记录被多个事务更新，那么，就会产生多个版本的记录。

以某一行数据做为例子：

 

通过两次事务的操做，value从22变成了19，同时，保留了三个事务id，1五、2五、30。

在每一个记录多版本的基础上，须要利用“一致性视图”，来作版本的可见性判断。

这里，咱们要区分MySQL里面的两个”视图”概念：

• 一个是view，经过语法create view … 实现，主要建立一个虚拟表，用来执行查询语句。
• 一个是InnoDB用来实现mvcc的一致性视图（consistent read view），纯逻辑概念，没有物理结构，定义了在事务期间，你能看到哪些版本的数据。

咱们全文提到的“视图”都是第二种，主要是支持InnoDB在“读已提交”和“可重复读”级别的并发访问问题。

• “读未说起”级别下，没有一致性视图
• “读已提交”级别下，会在 每一个SQL开始执行的时候 建立一致性视图
• “可重复读”级别下，会在 每一个事务开始的时候 建立一致性视图
• “串行化”级别下，直接经过加锁避免并发问题

下面，咱们简单介绍一下建立一致性视图的逻辑。

以“可重复读”级别为例。

• 当一个事务开启的时候，会向系统申请一个新事务id
• 此时，可能还有多个正在进行的其余事务没有提交，所以在瞬时时刻，是有多个活跃的未提交事务id
• 将这些未提交的事务id组成一个数组，数组里面最小的事务id记录为低水位，当前系统建立过的事务id的最大值+1记录为高水位
• 这个数组array 和 高水位，就组成了“一致性视图”。

有了一致性视图后，咱们就能够判断一行数据的多版本可见性了，不管是“读已提交”仍是“可重复读”级别，可见性判断规则是同样的，区别在于建立快照（一致性视图）的时间。

在当前事务中，读取其余某一行的记录，对其中的版本号的可见性判断有五种状况（建议本身跟着捋一捋，挺重要的）：

• 若是版本号小于“低水位”，说明事务已经提交，那确定 可见；
• 若是版本号大于“高水位”，说明这行数据的这个事务id版本是在快照后产生的，那确定 不可见；
• 若是版本号在事务数组array中，说明这个事务还没提交，因此 不可见；
• 若是版本号不在事务数组array中，且低于高水位，说明这个事务已经提交，因此 可见；
• 固然，不管何时，本身的事务id中的任何变化，都是可见的

能够看看下面这个例子，更容易理解。

系统建立过的事务id：1,2,3,4,5,6,7,8,9,10,11,12,13,14,15

事务A启动，拍个快照

此时未提交的事务id有：7，8，9

一致性视图：数组array[7,8,9] + 高水位16（15+1）

对于任意一行数据的可见性判断以下：

1）小于7的，可见

2）大于16的，说明是快照后产生的，不可见

3）10-15，不在数组array中，说明已经提交了，可见

4）7，8，9在array中，说明未提交，不可见

两个重要结论：

• InnoDB 利用了“全部数据都有多个版本”的这个特性，实现了“秒级建立快照”的能力。
• MVCC的实现，就是根据当前事务的事务id为依据建立“一致性视图”，利用一致性视图来判断数据版本的可见性。

3.隔离性实战

下面，咱们来两个实战案例，将上面的基础概念与实现融会贯通吧。

1）并发select&update 案例

id=1 的value初始为1。

 

咱们看下，在不一样隔离级别，Time五、Time七、Time9事务A查询到的value 分布为多少。

• “读未提交”：2，2，2
• “读以提交”：1，2，2
• “可重复读”：1，1，2
• 串行化：1，1，2（注意，这里在事务A提交前，事务B都会阻塞，直到事务A提交后才能执行）

2）并发update案例

id=1 的value初始为1，在可重复读级别：

 

咱们看一下，你猜猜事务A和事务B读取的value是多少？

答案是：1 和 3

可能会产生困惑，事务A在启动后快照，因此读到了1是正常的，可是事务2在启动的时候快照了，而后在本身的事务中+1，怎么会读到3而不是2呢？

缘由很简单，即便是在可重复读的级别，事务 更新数据 的时候，只能用当前读（想一想也能理解，否则update就出现数据不一致了）。

若是当前的记录的行锁被其余事务占用的话，就须要进入锁等待。而读提交的逻辑和可重复读的逻辑相似，它们最主要的区别是：在可重复读隔离级别下，只须要在事务开始的时候建立一致性视图，以后事务里的其余查询都共用这个一致性视图；在读提交隔离级别下，每个语句执行前都会从新算出一个新的视图。

这里，咱们须要注意的是事务的启动时机。

• begin/start transaction 命令并非一个事务的起点，在执行到它们以后的第一个操做 InnoDB 表的语句，事务才真正启动,一致性视图是在执行第一个快照读语句时建立的。
• 若是你想要立刻启动一个事务，可使用 start transaction with consistent snapshot 这个命令，一致性视图是在执行 start transaction with consistent snapshot 时建立的。

4.关于幻读

首先明确一下，什么是幻读？开篇介绍了什么是幻读，这里再申明一下幻读出现的场景

• 第一：事务的隔离级别为可重复读，且是当前读
• 第二：幻读仅专指新插入的行，在范围查询中，后一次查询出现了新的数据行。

前文已经提到了，对于普通数据库，须要到可串行化的隔离级别才能解决幻读问题。

而对于InnoDB存储引擎来讲，在可重复读级别下就能解决幻读问题。

InnoDB存储引擎有三种行锁算法：

• 行锁：当个行记录上的锁
• 间隙锁：Gap Lock，锁定一个范围，但不包含记录自己
• Next-Key Lock:就是行锁+间隙锁，同时锁上一个范围，而且锁定记录自己

InnoDB就是经过Next-Key Lock解决了幻读的问题，具体内容能够看我以前的文章： 前阿里数据库专家总结的MySQL里的各类锁（下篇）

 

看到这里了，原创不易，点个关注、点个赞吧，你最好看了～

知识碎片从新梳理，构建Java知识图谱：https://github.com/saigu/JavaKnowledgeGraph（历史文章查阅很是方便）

扫码关注个人公众号“阿丸笔记”，第一时间获取最新更新。同时能够免费获取海量Java技术栈电子书、各个大厂面试题。