详解MySQL的事务ACID实现原理与MVCC

总览事务ACID：

原子性： 语句要么都执行，要么都不是执行，是事务最核心的特性，事务本身来说就是以原子性历来定义的，实现主要是基于undo log

持久性： 保证事务提交之后，不会因为宕机等其他的原因而导致数据的丢失，主要是基于 redo log实现

隔离性： 保证事务与事务之间的执行是相互隔离的，事务的执行不会受到其他事务的影响。InnoDB存储引擎默认的数据库隔离级别是 RR ，RR又主要是基于锁机制，数据的隐藏列，undo log类 以及 next-key lock机制

一致性： 事务追求的最终目标，一致性的实现即需要数据库层面的保障，也需要应用层面的保障。

redo log && undolog：

InnoDB提供了两种事务日志

redo log(重做日志)：

重做日志保证的是事物的持久性

redo log被引入来解决由于MySQL宕机数据无法持久化问题：当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。

InnoDB能够实现回滚的主要原因就是靠undo log：当事务对数据库进行修改的时候，InnoDB会生成对应的undo log ；如果此时事务执行失败或者调用rollback，导致事务出现回滚情况，可以利用undo log中的信息将数据回滚到修改前的样子。

undo log(回滚日志)：

回滚日志保证的是事务的原子性和隔离性

undo log 属于一个逻辑日志，它用来记录的是sql执行相关的信息。对于一个insert语句在回滚时候会执行delete，相反也是如此。例如对于一个update在执行的时候，其生成的undolog 中会包含被修改的主键（以便知道修改了哪些行，修改了哪些列）以便在回滚时候能够使用这些记录的信息将数据还原到执行之前。

详解事务ACID：

原子性

概念描述：

原子性是指一个事务是一个不可分割的工作单位，其中的操作要么都做，要么全部做。如果对于一个事务来说其中的sql语句执行失败，则已经执行的语句也必须要回滚，数据库退回到事务之前的状态。

实现原理：

原子性基于回滚机制和undo log回滚日志

在说明原子性原理之前，首先介绍一下MySQL的事务日志。MySQL的日志有很多种，如二进制日志、错误日志、查询日志、慢查询日志等，此外InnoDB存储引擎还提供了两种事务日志：redo log(重做日志)和undo log(回滚日志)。其中redo log用于保证事务持久性；undo log则是事务原子性和隔离性实现的基础。

下面说回undo log。实现原子性的关键，是当事务回滚时能够撤销所有已经成功执行的sql语句。InnoDB实现回滚，靠的是undo log：当事务对数据库进行修改时，InnoDB会生成对应的undo log；如果事务执行失败或调用了rollback，导致事务需要回滚，便可以利用undo log中的信息将数据回滚到修改之前的样子。

undo log属于逻辑日志，它记录的是sql执行相关的信息。当发生回滚时，InnoDB会根据undo log的内容做与之前相反的工作：对于每个insert，回滚时会执行delete；对于每个delete，回滚时会执行insert；对于每个update，回滚时会执行一个相反的update，把数据改回去。

以update操作为例：当事务执行update时，其生成的undo log中会包含被修改行的主键(以便知道修改了哪些行)、修改了哪些列、这些列在修改前后的值等信息，回滚时便可以使用这些信息将数据还原到update之前的状态。

持久性：

概念描述：

事务一旦提交，他对数据库的改变就是永久的，接下来的其他操作或是故障都不应该对其造成影响。

实现原理：

InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为刷脏）。

Buffer Pool的使用大大提高了读写数据的效率，但是也带了新的问题：如果MySQL宕机，而此时Buffer Pool中修改的数据还没有刷新到磁盘，就会导致数据的丢失，事务的持久性无法保证。

于是，redo log被引入来解决这个问题：当数据修改时，除了修改Buffer Pool中的数据，还会在redo log记录这次操作；当事务提交时，会调用fsync接口对redo log进行刷盘。如果MySQL宕机，重启时可以读取redo log中的数据，对数据库进行恢复。

redo log采用的是WAL（Write-ahead logging，预写式日志），所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。

隔离性：

概念描述：

与原子性，持久性侧重于研究事务本身不同，隔离性研究的是不同事务之间的相互影响。是指，事务内部的操作与其他的事务是隔离的，并发执行的各个事务之间是不能相互干扰。

实现原理：

隔离性，对应了事务隔离级别中的 Serializable，但是在我们的实际的开发中很少使用到可串行化。隔离性追求的是并发情形下事务之间不会相互干扰，简单起见，我们仅考虑最简单的读操作和写操作(暂时不考虑带锁读等特殊操作)，那么隔离性的探讨，主要可以分为两个方面：

1.(一个事务)写操作对(另一个事务)写操作的影响：锁机制保证隔离性

2.(一个事务)写操作对(另一个事务)读操作的影响：MVCC保证隔离性

锁机制：

首先来看两个事务的写操作之间的相互影响。隔离性要求同一时刻只能有一个事务对数据进行写操作，InnoDB通过锁机制来保证这一点。锁机制的基本原理可以概括为：事务在修改数据之前，需要先获得相应的锁；获得锁之后，事务便可以修改数据；该事务操作期间，这部分数据是锁定的，其他事务如果需要修改数据，需要等待当前事务提交或回滚后释放锁。

行锁与表锁：

按照粒度，分为表锁与行锁：MyISAM 支持表锁，InnoDB 支持表锁和行级锁，默认是行级锁。表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发送锁冲突的概率比较高，并发处理效果较低。行级锁： 开销大，加锁慢，会出现死锁，锁定粒度较大，发生锁冲突的概率会小一点，并发处理的效果高

下面开始介绍事务过程中的可能出现的情况，其实下面所介绍的也都是与锁隔离性相关的问题： 先来介绍一下可能出现的问题：

脏读，不可重复读和幻读（就是并发问题）

 脏读、不可重复读和幻读：

（1）脏读：当前事务(A)中可以读到其他事务(B)未提交的数据（脏数据），这种现象是脏读。举例如下（以账户余额表为例）：

（2）不可重复读：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。脏读与不可重复读的区别在于：前者读到的是其他事务未提交的数据，后者读到的是其他事务已提交的数据。举例如下：

（3）幻读：在事务A中按照某个条件先后两次查询数据库，两次查询结果的条数不同，这种现象称为幻读。不可重复读与幻读的区别可以通俗的理解为：前者是数据变了，后者是数据的行数变了。举例如下：

MVCC：

实现原理：

前面讲到了 RR解决了 脏读，不可重复读，幻读等问题使用到的就是MVCC（Multi-Version Concurrency Control） 既多版本的并发控制：在同一个时刻，不同的事物读取到的数据可能是不同的（多版本）。对于MVCC来说最大的优点就是读不加锁，因此读写不冲突，并发性能好InnoDB实现MVCC，多个版本的数据可以共存，主要是依靠数据的隐藏列(也可以称之为标记位)、undo log和ReadView（读视图）。其中数据的隐藏列包括了该行数据的版本号、删除时间、指向undo log的指针等等；当使用快照读（不加锁读）读取数据时，MySQL可以通过对比隐藏列和ReadView的属性判断是否需要回滚并找到回滚需要的undo log，从而实现MVCC。

1）隐藏列：InnoDB中每行数据都有隐藏列，隐藏列中包含了本行数据的事务id、指向undo log的指针等。

2）基于undo log的版本链：前面说到每行数据的隐藏列中包含了指向undo log的指针（ROLL_PTR回滚指针），而每条undo log也会指向更早版本的undo log，从而形成一条版本链。

3）ReadView：

ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务（未提交的）id。

通过隐藏列和版本链，MySQL可以将数据恢复到指定版本；但是具体要恢复到哪个版本，则需要根据ReadView来确定。所谓ReadView，是指事务（记做事务A）在某一时刻给整个事务系统（trx_sys）打快照，之后再进行读操作时，会将读取到的数据中的事务id与trx_sys快照比较，从而判断数据对该ReadView是否可见，即对事务A是否可见。

ReadView中包含了四个核心字段：

而在readview中就规定了版本链数据的访问规则：trx_id 代表当前undolog版本链对应事务ID。

不同的隔离级别，生成ReadView的时机不同：

READ COMMITTED ：在事务中每一次执行快照读时生成ReadView。

REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。

快照读：

简单的select（不加锁）就是快照读，快照读，读取的是记录数据的可见版本，有可能是历史数据，

不加锁，是非阻塞读。

• Read Committed：每次select，都生成一个快照读。

• Repeatable Read：开启事务后第一个select语句才是快照读的地方。

• Serializable：快照读会退化为当前读。

示例：

RC隔离级别：

读已提交：

寻找不活跃且已经提交的事务对应的版本链数据

RC隔离级别下，在事务中每一次执行快照读时生成ReadView。我们就来分析事务5中，两次快照读读取数据，是如何获取数据的?

在事务5中，查询了两次id为30的记录，由于隔离级别为Read Committed，所以每一次进行快照读都会生成一个ReadView，那么两次生成的ReadView如下：

那么这两次快照读在获取数据时，就需要根据所生成的ReadView以及ReadView的版本链访问规则，

到undolog版本链中匹配数据，最终决定此次快照读返回的数据。

A. 先来看第一次快照读具体的读取过程：

B. 再来看第二次快照读具体的读取过程:

RR隔离级别：

RR隔离级别下，仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView。 而RR 是可

重复读，在一个事务中，执行两次相同的select语句，查询到的结果是一样的。

那MySQL是如何做到可重复读的呢?

我们看到，在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该

ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返

回的结果也是一样的。

所以呢，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。

而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证。

基于MVCC的RR隔离性级别扩展：

下面以RR隔离级别为例，结合前文提到的几个问题分别说明。

（1）脏读

当事务A在T3时刻读取zhangsan的余额前，会生成ReadView，由于此时事务B没有提交仍然活跃，因此其事务id一定在ReadView的rw_trx_ids中，因此根据前面介绍的规则，事务B的修改对ReadView不可见。接下来，事务A根据指针指向的undo log查询上一版本的数据，得到zhangsan的余额为100。这样事务A就避免了脏读。

（2）不可重复读

当事务A在T2时刻读取zhangsan的余额前，会生成ReadView。此时事务B分两种情况讨论，一种是如图中所示，事务已经开始但没有提交，此时其事务id在ReadView的rw_trx_ids中；一种是事务B还没有开始，此时其事务id大于等于ReadView的low_limit_id。无论是哪种情况，根据前面介绍的规则，事务B的修改对ReadView都不可见。

当事务A在T5时刻再次读取zhangsan的余额时，会根据T2时刻生成的ReadView对数据的可见性进行判断，从而判断出事务B的修改不可见；因此事务A根据指针指向的undo log查询上一版本的数据，得到zhangsan的余额为100，从而避免了不可重复读。

（3）幻读

MVCC避免幻读的机制与避免不可重复读非常类似。

当事务A在T2时刻读取0

当事务A在T5时刻再次读取0

扩展：

前面介绍的MVCC，是RR隔离级别下“非加锁读”实现隔离性的方式。下面是一些简单的扩展。

（1）读已提交（RC）隔离级别下的非加锁读

RC与RR一样，都使用了MVCC，其主要区别在于：

RR是在事务开始后第一次执行select前创建ReadView，直到事务提交都不会再创建。根据前面的介绍，RR可以避免脏读、不可重复读和幻读。

RC每次执行select前都会重新建立一个新的ReadView，因此如果事务A第一次select之后，事务B对数据进行了修改并提交，那么事务A第二次select时会重新建立新的ReadView，因此事务B的修改对事务A是可见的。因此RC隔离级别可以避免脏读，但是无法避免不可重复读和幻读。

（2）加锁读与next-key lock

按照是否加锁，MySQL的读可以分为两种：

一种是非加锁读，也称作快照读、一致性读，使用普通的select语句，这种情况下使用MVCC避免了脏读、不可重复读、幻读，保证了隔离性。

另一种是加锁读，查询语句有所不同，如下所示：

#共享锁读取 select...lock in share mode #排它锁读取 select...for update

加锁读在查询时会对查询的数据加锁（共享锁或排它锁）。由于锁的特性，当某事务对数据进行加锁读后，其他事务无法对数据进行写操作，因此可以避免脏读和不可重复读。而避免幻读，则需要通过next-key lock。next-key lock是行锁的一种，实现相当于record lock(记录锁) + gap lock(间隙锁)；其特点是不仅会锁住记录本身(record lock的功能)，还会锁定一个范围(gap lock的功能)。因此，加锁读同样可以避免脏读、不可重复读和幻读，保证隔离性。

一致性：

概念描述：

一致性是指事物执行结束后，数据库的完整性没有被破坏，事务执行的前后都是合法的数据状态。数据库的完整性包括但是不限于：实体完整性（如行的主键存在且唯一）列完整性（如字段的类型，大小，长度符合要求），外键约束（外键约束还存在）用户自定义完整性（如转账前后，两个账户的和应该是不变的）。

实现原理：

可以说，一致性是事物追求的最终目标，前面提到的原子性，隔离性，持久性都是为了保证数据库的一致性。此外除了数据库底层的保障，一致性的实现也需要应用层的保障。

基于回滚原理，使用redo log和undo log共同保证

保证原子性、持久性和隔离性，如果这些特性无法保证，事务的一致性也无法保证

数据库本身提供保障，例如不允许向整形列插入字符串值、字符串长度不能超过列的限制等

应用层面进行保障，例如如果转账操作只扣除转账者的余额，而没有增加接收者的余额，无论数据库实现的多么完美，也无法保证状态的一致

Mysql的隔离级别：

未提交读（RU）

所有事务都可以看到其他未提交事务的执行结果， 即在未提交读级别，事务的修改，即使没有提交，对其他事务也是可见的，该隔离级别很少使用到，也被称为脏读。

提交读（RC）

大多数的数据库默认的隔离级别是 提交读，但是对于Mysql不是 提交读：一个事务开始时，只能“看见”已经提交的事物所做的修改。换句话说一个事务从开始直到提交之前，所做的任何修改都是对其他事务不可见的。这个级别也叫作不可重复读。

可重复读（RR）

解决了脏读了问题，该级别保证了在同一个事务多次读取同样记录的结果是一致的。但是可重复读还是无法解决幻读的问题： 什么是幻读 指的是当某个事务在读取某个范围内的记录的时候，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时候 就会产生 幻行**。InnoDB 和XtraDB 存储引擎通过版本并发控制解决而了幻读的问题可重复读是Mysql的事务的默认隔离级别。**注意在 SQL标准中，RR是无法避免幻读问题，但是InnoDB实现的RR避免了幻读问题。

可串行化读

是最高的隔离级别，通过强制事务串行化执行，避免了前面所说到的幻读的问题。就是可串行化 会在读取的每一行数据上都加上锁，但是这样会导致超时和锁争用问题。

在实际应用中，读未提交在并发时会导致很多问题，而性能相对于其他隔离级别提高却很有限，因此使用较少。可串行化强制事务串行，并发效率很低，只有当对数据一致性要求极高且可以接受没有并发时使用，因此使用也较少。因此在大多数数据库系统中，默认的隔离级别是读已提交(如Oracle)或可重复读（后文简称RR）。

可以通过如下两个命令分别查看全局隔离级别和本次会话的隔离级别：

InnoDB默认的隔离级别是RR，后文会重点介绍RR。需要注意的是，在SQL标准中，RR是无法避免幻读问题的，但是InnoDB实现的RR避免了幻读问题。

问题与总结：

（1）刷脏是随机IO，因为每次修改的数据位置随机，但写redo log是追加操作，属于顺序IO

（2）那为什么每一次提交事务，要刷新redo log 到磁盘中呢，而不是直接将buffer pool中的脏页刷新到磁盘呢 ?

因为在业务操作中，我们操作数据一般都是随机读写磁盘的，而不是顺序读写磁盘。 而redo log在往磁盘文件中写入数据，由于是日志文件，所以都是顺序写的。顺序写的效率，要远大于随机写。这种先写日志的方式，称之为 WAL（Write-Ahead Logging）。

（3）WAL预写式日志，所有修改先写入日志，再更新到Buffer Pool，保证了数据不会因MySQL宕机而丢失，从而满足了持久性要求。