mysql 隔离级别实现原理,关于mysql:深入理解MySQL中事务隔离级别的实现原理

前言

说到数据库事务，大家脑子里肯定很容易蹦出一堆事务的相干常识，如事务的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

感觉不错的话请帮忙珍藏点赞~