深入理解MySQL中事务隔离级别的实现原理

前言

说到数据库事务，大家脑子里一定很容易蹦出一堆事务的相关知识，如事务的ACID特性，隔离级别，解决的问题（脏读，不可重复读，幻读）等等，但是可能很少有人真正的清楚事务的这些特性又是怎么实现的，为什么要有四个隔离级别。

今天我们就先来聊聊MySQL中事务的隔离性的实现原理，后续还会继续出文章分析其他特性的实现原理。

当然MySQL博大精深，文章疏漏之处在所难免，欢迎批评指正。

说明

MySQL的事务实现逻辑是位于引擎层的，并且不是所有的引擎都支持事务的，下面的说明都是以InnoDB引擎为基准。

定义

隔离性（isolation）指的是不同事务先后提交并执行后，最终呈现出来的效果是串行的，也就是说，对于事务来说，它在执行过程中，感知到的数据变化应该只有自己操作引起的，不存在其他事务引发的数据变化。

隔离性解决的是并发事务出现的问题。

标准SQL隔离级别

隔离性最简单的实现方式就是各个事务都串行执行了，如果前面的事务还没有执行完毕，后面的事务就都等待。但是这样的实现方式很明显并发效率不高，并不适合在实际环境中使用。

为了解决上述问题，实现不同程度的并发控制，SQL的标准制定者提出了不同的隔离级别：未提交读（read uncommitted）、提交读（read committed）、可重复读（repeatable read）、序列化读（serializable）。其中最高级隔离级别就是序列化读，而在其他隔离级别中，由于事务是并发执行的，所以或多或少允许出现一些问题。见以下的矩阵表：

隔离级别（+:允许出现，-:不允许出现）	脏读	不可重复读	幻读
未提交读	+	+	+
提交读	-	+	+
可重复读	-	-	+
序列化读	-	-	-

注意，MySQL的InnoDB引擎在提交读级别通过MVCC解决了不可重复读的问题，在可重复读级别通过间隙锁解决了幻读问题，具体见下面的分析。

实现原理

标准SQL事务隔离级别实现原理

我们上面遇到的问题其实就是并发事务下的控制问题，解决并发事务的最常见方式就是悲观并发控制了（也就是数据库中的锁）。标准SQL事务隔离级别的实现是依赖锁的，我们来看下具体是怎么实现的：

事务隔离级别	实现方式
未提交读（RU）	事务对当前被读取的数据不加锁； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加行级共享锁，直到事务结束才释放。
提交读（RC）	事务对当前被读取的数据加行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁； 事务在更新某数据的瞬间（就是发生更新的瞬间）࿰