MySQL事务之ACID实现原理（全方位解读）

前言

我们都知道MySQL事务的ACID，但是按照严格的标准，只有同时满足ACID特性才是事务；但是在各大数据库厂商的实现中，真正满足ACID的事务少之又少。例如MySQL的NDB Cluster事务不满足持久性和隔离性；InnoDB默认事务隔离级别是可重复读，不满足隔离性；Oracle默认的事务隔离级别为READ COMMITTED，不满足隔离性……
因此与其说ACID是事务必须满足的条件，不如说它们是衡量事务的四个维度。很多的文章也都会介绍事务ACID是什么，但是却很少有人能够介绍到事务ACID的实现原理。今天这里就来介绍一下实现原理。

---

原子性

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

实现原理

对介绍原子性之前，对于Mysql的事务日志来说，InnoDB提供了两种事务日志： redo log(重做日志)和 undo log(回滚日志)。其中的
重做日志保证的是事物的持久性，
回滚日志保证的是事务的原子性和隔离性
实现的基础。
下面来具体介绍对于原子性实现的关键： 当事务出现回滚时候能够撤销所有已经成功执行的sql语句。
InnoDB能够实现回滚的主要原因就是靠undo log： 当事务对数据库进行修改的时候，InnoDB会生成对应的undo log ；如果此时事务执行失败或者调动了 rollback，导致事务出现回滚情况，可以利用undo log中的信息将数据回滚到修改前的样子

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

持久性

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

实现的原理

前面提到了InnoDB实现了两个事务日志，首先我们来聊一下redo log 存在的背景。

InnoDB作为MySQL的存储引擎（在5.1版本以后），数据是存放在磁盘中的，但如果每次读写数据都需要磁盘IO，效率会很低。为此，InnoDB提供了缓存(Buffer Pool)，Buffer Pool中包含了磁盘中部分数据页的映射，作为访问数据库的缓冲：
当从数据库读取数据时，会首先从Buffer Pool中读取，如果Buffer Pool中没有，则从磁盘读取后放入Buffer Pool；当向数据库写入数据时，会首先写入Buffer Pool，Buffer Pool中修改的数据会定期刷新到磁盘中（这一过程称为