共计 4851 个字符，预计需要花费 13 分钟才能阅读完成。
前言
说到数据库事务，大家脑子里肯定很容易蹦出一堆事务的相干常识，如事务的 ACID 个性，隔离级别，解决的问题（脏读，不可反复读，幻读）等等，然而可能很少有人真正的分明事务的这些个性又是怎么实现的，为什么要有四个隔离级别。
明天咱们就先来聊聊 MySQL 中事务的隔离性的实现原理，后续还会持续出文章剖析其余个性的实现原理。
当然 MySQL 博大精深，文章疏漏之处在劫难逃，欢送批评指正。
阐明
MySQL 的事务实现逻辑是位于引擎层的，并且不是所有的引擎都反对事务的，上面的阐明都是以 InnoDB 引擎为基准。
定义
隔离性（isolation）指的是不同事务先后提交并执行后，最终出现进去的成果是串行的，也就是说，对于事务来说，它在执行过程中，感知到的数据变动应该只有本人操作引起的，不存在其余事务引发的数据变动。
隔离性解决的是并发事务呈现的问题。
规范 SQL 隔离级别
隔离性最简略的实现形式就是各个事务都串行执行了，如果后面的事务还没有执行结束，前面的事务就都期待。然而这样的实现形式很显著并发效率不高，并不适宜在理论环境中应用。
为了解决上述问题，实现不同水平的并发管制，SQL 的规范制定者提出了不同的隔离级别：未提交读（read uncommitted）、提交读（read committed）、可反复读（repeatable read）、序列化读（serializable）。其中最高级隔离级别就是序列化读，而在其余隔离级别中，因为事务是并发执行的，所以或多或少容许呈现一些问题。见以下的矩阵表：
| 隔离级别（+: 容许呈现，-: 不容许呈现） | 脏读 | 不可反复读 | 幻读 |
|---|---|---|---|
| 未提交读 | + | + | + |
| 提交读 | – | + | + |
| 可反复读 | – | – | + |
| 序列化读 | – | – | – |
留神，MySQL 的 InnoDB 引擎在提交读级别通过 MVCC 解决了不可反复读的问题，在可反复读级别通过间隙锁解决了幻读问题，具体见上面的剖析。
实现原理
规范 SQL 事务隔离级别实现原理
咱们下面遇到的问题其实就是并发事务下的管制问题，解决并发事务的最常见形式就是乐观并发管制了（也就是数据库中的锁）。规范 SQL 事务隔离级别的实现是依赖锁的，咱们来看下具体是怎么实现的：
| 事务隔离级别 | 实现形式 |
|---|---|
| 未提交读（RU） | 事务对以后被读取的数据不加锁；
事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加 行级共享锁，直到事务完结才开释。 |
| 提交读（RC） | 事务对以后被读取的数据加 行级共享锁（当读到时才加锁），一旦读完该行，立刻开释该行级共享锁；
事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加 行级排他锁，直到事务完结才开释。 |
| 可反复读（RR） | 事务在读取某数据的霎时（就是开始读取的霎时），必须先对其加 行级共享锁，直到事务完结才开释；
事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加 行级排他锁，直到事务完结才开释。 |
| 序列化读（S） | 事务在读取数据时，必须先对其加 表级共享锁，直到事务完结才开释；
事务在更新数据时，必须先对其加 表级排他锁，直到事务完结才开释。 |
能够看到，在只应用锁来实现隔离级别的管制的时候，须要频繁的加锁解锁，而且很容易产生读写的抵触（例如在 RC 级别下，事务 A 更新了数据行 1，事务 B 则在事务 A 提交前读取数据行 1 都要期待事务 A 提交并开释锁）。
为了不加锁解决读写抵触的问题，MySQL 引入了 MVCC 机制，具体可见我以前的剖析文章：一文读懂数据库中的乐观锁和乐观锁和 MVCC。
InnoDB 事务隔离级别实现原理
在往下剖析之前，咱们有几个概念须要先理解下：
1、锁定读和一致性非锁定读
锁定读：在一个事务中，被动给读加锁，如 SELECT … LOCK IN SHARE MODE 和 SELECT … FOR UPDATE。别离加上了行共享锁和行排他锁。锁的分类可见我以前的剖析文章：你应该理解的 MySQL 锁分类)。
https://dev.mysql.com/doc/refman/8.0/en/innodb-locking-reads.html
一致性非锁定读：InnoDB 应用 MVCC 向事务的查问提供某个工夫点的数据库快照。查问会看到在该工夫点之前提交的事务所做的更改，而不会看到稍后或未提交的事务所做的更改（本事务除外）。也就是说在开始了事务之后，事务看到的数据就都是事务开启那一刻的数据了，其余事务的后续批改不会在本次事务中可见。
Consistent read 是 InnoDB 在 RC 和 RR 隔离级别解决 SELECT 语句的默认模式。一致性非锁定读不会对其拜访的表设置任何锁，因而，在对表执行一致性非锁定读的同时，其它事务能够同时并发的读取或者批改它们。
https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html
2、以后读和快照读
以后读
读取的是最新版本，像 UPDATE、DELETE、INSERT、SELECT … LOCK IN SHARE MODE、SELECT … FOR UPDATE 这些操作都是一种以后读，为什么叫以后读？就是它读取的是记录的最新版本，读取时还要保障其余并发事务不能批改以后记录，会对读取的记录进行加锁。
快照读
读取的是快照版本，也就是历史版本，像不加锁的 SELECT 操作就是快照读，即不加锁的非阻塞读；快照读的前提是隔离级别不是未提交读和序列化读级别，因为未提交读总是读取最新的数据行，而不是合乎以后事务版本的数据行，而序列化读则会对表加锁。
3、隐式锁定和显式锁定
隐式锁定
InnoDB 在事务执行过程中，应用两阶段锁协定（不被动进行显示锁定的状况）：
- 随时都能够执行锁定，InnoDB 会依据隔离级别在须要的时候主动加锁；
- 锁只有在执行 commit 或者 rollback 的时候才会开释，并且所有的锁都是在同一时刻被开释。
显式锁定
- InnoDB 也反对通过特定的语句进行显示锁定（存储引擎层）
select ... lock in share mode // 共享锁
select ... for update // 排他锁- MySQL Server 层的显示锁定：
lock table
unlock table理解完下面的概念后，咱们来看下 InnoDB 的事务具体是怎么实现的（上面的读都指的是非被动加锁的 select）
| 事务隔离级别 | 实现形式 |
|---|---|
| 未提交读（RU） | 事务对以后被读取的数据不加锁，都是 以后读；
事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加 行级共享锁，直到事务完结才开释。 |
| 提交读（RC） | 事务对以后被读取的数据不加锁，且是 快照读；
事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加 行级排他锁（Record），直到事务完结才开释。 通过快照，在这个级别 MySQL 就解决了不可反复读的问题 |
| 可反复读（RR） | 事务对以后被读取的数据不加锁，且是 快照读；
事务在更新某数据的霎时（就是产生更新的霎时），必须先对其加 行级排他锁（Record，GAP，Next-Key），直到事务完结才开释。 通过间隙锁，在这个级别 MySQL 就解决了幻读的问题 |
| 序列化读（S） | 事务在读取数据时，必须先对其加 表级共享锁 ，直到事务完结才开释，都是 以后读；
事务在更新数据时，必须先对其加 表级排他锁，直到事务完结才开释。 |
能够看到，InnoDB 通过 MVCC 很好的解决了读写抵触的问题，而且提前一个级别就解决了规范级别下会呈现的幻读和不可反复读问题，大大晋升了数据库的并发能力。
一些常见误区
幻读到底包不包含了 delete 的状况?
不可反复读：前后屡次读取一行，数据内容不统一，针对其余事务的 update 和 delete 操作。为了解决这个问题，应用行共享锁，锁定到事务完结（也就是 RR 级别，当然 MySQL 应用 MVCC 在 RC 级别就解决了这个问题）
幻读：当同一个查问在不同工夫生成不同的行汇合时就是呈现了幻读，针对的是其余事务的 insert 操作，为了解决这个问题，锁定整个表到事务完结（也就是 S 级别，当然 MySQL 应用间隙锁在 RR 级别就解决了这个问题）
网上很多文章提到幻读和提交读的时候，有的说幻读包含了 delete 的状况，有的说 delete 应该属于提交读的问题，那到底假相如何呢？咱们理论来看下 MySQL 的官网文档（如下）
The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a
SELECT) is executed twice, but returns a row the second time that was not returned the first time, the row is a“phantom”row.https://dev.mysql.com/doc/refman/5.7/en/innodb-next-key-locking.html
能够看到，幻读针对的是后果集前后发生变化，所以看起来 delete 的状况应该归为幻读，然而咱们理论剖析下下面列出的规范 SQL 在 RR 级别的实现原理就晓得，规范 SQL 的 RR 级别是会对查到的数据行加行共享锁，所以这时候其余事务想删除这些数据行其实是做不到的，所以在 RR 下，不会呈现因 delete 而呈现幻读景象，也就是幻读不蕴含 delete 的状况。
MVCC 能解决了幻读问题?
网上很多文章会说 MVCC 或者 MVCC+ 间隙锁解决了幻读问题，实际上 MVCC 并不能解决幻读问题。如以下的例子：
begin;
#假如 users 表为空，上面查出来的数据为空
select * from users; #没有加锁
#此时另一个事务提交了，且插入了一条 id= 1 的数据
select * from users; #读快照，查出来的数据为空
update users set name='mysql' where id=1;#update 是以后读，所以更新胜利，并生成一个更新的快照
select * from users; #读快照，查出来 id 为 1 的一条记录，因为 MVCC 能够查到以后事务生成的快照
commit;能够看到前后查出来的数据行不统一，产生了幻读。所以说只有 MVCC 是不能解决幻读问题的，解决幻读问题靠的是间隙锁。如下：
begin;
#假如 users 表为空，上面查出来的数据为空
select * from users lock in share mode; #加上共享锁
#此时另一个事务 B 想提交且插入了一条 id= 1 的数据，因为有间隙锁，所以要期待
select * from users; #读快照，查出来的数据为空
update users set name='mysql' where id=1;#update 是以后读，因为不存在数据，不进行更新
select * from users; #读快照，查出来的数据为空
commit;
#事务 B 提交胜利并插入数据留神，RR 级别下想解决幻读问题，须要咱们显式加锁，不然查问的时候还是不会加锁的。
版权申明
转载请注明作者和文章出处
作者: X 学生
https://segmentfault.com/a/1190000025156465
感觉不错的话请帮忙珍藏点赞~
