超干货！为了让你彻底弄懂MySQL事务日志我通宵肝

　　还记得刚上研究生的时候，导师常挂在嘴边的一句话，“科研的基础不过就是数据而已。”如今看来，无论是人文社科，还是自然科学，或许都可在一定程度上看作是数据的科学。

　　倘若剥开研究领域的外衣，将人的操作抽象出来，那么科研的过程大概就是根据数据流动探索其中的未知信息吧。当然科学研究的范畴涵盖甚广，也不是一两句话能够拎得清的。不过从这个角度上的阐述，也只是为了引出数据的重要性。

　　在当今社会，充斥着大量的数据。从众多APP上的账户资料到银行信用体系等个人档案，都离不开对大量数据的组织、存储和管理。而这，便是数据库存在的目的和价值。

　　目前数据库的类型主要分为两种，一种是关系型数据库，另一种是非关系型数据库（NoSQL）。而我们今天的主角MySQL就是关系型数据库中的一种。

　　关系型数据库，顾名思义，是指存储的数据之间具有关系。这种所谓的关系通常用二维表格中的行列来表示，即一个二维表的逻辑结构能够反映表中数据的存储关系。

　　概念总是拗口难懂的。那么简单来说，关系型数据库的存储就是按照表格进行的。数据的存储实际上就是对一个或者多个表格的存储。通过对这些表格进行分类、合并、连接或者选取等运算来实现对数据库的管理。常见的关系型数据库有MySQL、Oracle、DB2和SqlServer等。

　　非关系型数据库（NoSQL）是相对于关系型数据库的一种泛指，它的特点是去掉了关系型数据库中的关系特性，从而可获得更好的扩展性。NoSQL并没有严格的存储方式，但采用不同的存储结构都是为了获得更高的性能和更高的并发。NoSQL根据存储方式可分为四大类，键值存储数据库、列存储数据库、文档型数据库和图形数据库。这四种数据的存储原理不尽相同，因而在应用场景上也有些许的差异。一般常用的有作为数据缓存的redis和分布式系统的HBase。目前常见的数据库排名可见网站：

　　关系型数据库与非关系型数据库本质上的区别就在于存储的数据是否具有一定的逻辑关系，由此产生的两类数据库看的性能和优劣势上也有一定的区别。二者对比可见下图。

　　在关系型数据库中，MySQL可以说是其中的王者。它是目前最流行的数据库之一，由瑞典 MySQL AB 公司开发，目前属于 Oracle 公司。MySQL数据库具有以下几个方面的优势：

　　MySQL的逻辑架构可分为四层，包括连接层、服务层、引擎层和存储层，各层的接互及作用如下图所示。需要注意的是，由于本文将主要讲解事务的实现原理，因此下文针对的都是InnoDB引擎下的情况。

　　**服务层：**定义有许多不同的模块，包括权限判断，SQL接口，SQL解析，SQL分析优化， 缓存查询的处理以及部分内置函数执行等。MySQL的查询语句在服务层内进行解析、优化、缓存以及内置函数的实现和存储。

　　**引擎层：**负责MySQL中数据的存储和提取。MySQL中的服务器层不管理事务，事务是由存储引擎实现的。其中使用最为广泛的存储引擎为InnoDB，的引擎都不支持事务。

　　事务是MySQL区别于NoSQL的重要特征，是保证关系型数据库数据一致性的关键技术。事务可看作是对数据库操作的基本执行单元，可能包含一个或者多个SQL语句。这些语句在执行时，要么都执行，要么都不执行。

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

　　：保证事务执行尽可能不受其他事务影响；InnoDB默认的隔离级别是RR，RR的实现主要基于锁机制、数据的隐藏列、undo log和类next-key lock机制。

　　事务的原子性就如原子操作一般，表示事务不可再分，其中的操作要么都做，要么都不做；如果事务中一个SQL语句执行失败，则已执行的语句也必须回滚，数据库退回到事务前的状态。只有0和1，没有值。

　　事务的原子性表明事务就是一个整体，当事务无法成功执行的时候，需要将事务中已经执行过的语句全部回滚，使得数据库回归到最初未开始事务的状态。

　　事务的原子性就是通过undo log日志进行实现的。当事务需要进行回滚时，InnoDB引擎就会调用undo log日志进行SQL语句的撤销，实现数据的回滚。

　　事务的持久性是指当事务提交之后，数据库的改变就应该是永久性的，而不是暂时的。这也就是说，当事务提交之后，任何操作甚至是系统的宕机故障都不会对原来事务的执行结果产生影响。

　　事务的持久性是通过InnoDB存储引擎中的redo log日志来实现的，具体实现思路见下文。

　　原子性和持久性是单个事务本身层面的性质，而隔离性是指事务之间应该保持的关系。隔离性要求不同事务之间的影响是互不干扰的，一个事务的操作与事务是相互隔离的。

　　由于事务可能并不只包含一条SQL语句，所以在事务的执行期间很有可能会有事务开始执行。因此多事务的并发性就要求事务之间的操作是相互隔离的。这一点跟多线程之间数据同步的概念有些类似。

　　事务之间的隔离，是通过锁机制实现的。当一个事务需要对数据库中的某行数据进行修改时，需要先给数据加锁；加了锁的数据，事务是不运行操作的，只能等待当前事务提交或回滚将锁释放。

　　锁机制并不是一个陌生的概念，在许多场景中都会利用到不同实现的锁对数据进行保护和同步。而在MySQL中，根据不同的划分标准，还可将锁分为不同的种类。

　　MySQL中不同的存储引擎能够支持的锁也是不一样的。MyIsam只支持表锁，而InnoDB同时支持表锁和行锁，且出于性能考虑，绝大多数情况下使用的都是行锁。

　　以上图为例，事务A在读取文章的阅读量时，读取到了事务B为提交的数据。如果事务B最后没有顺利提交，导致事务回滚，那么实际上阅读量并没有修改成功，而事务A却是读到的修改后的值，显然不合情理。

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

　　以上图为例，事务A在先后读取文章阅读量的数据时，结果却不一样。说明事务A在执行的过程中，阅读量的值被事务给修改了。这样使得数据的查询结果不再可靠，同样也不合实际。

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

　　以上图为例，当对0阅读量100的文章进行查询时，先查到了一个结果，后来查询到了两个结果。这表明同一个事务的查询结果数不一，行数不一致。这样的问题使得在根据某些条件对数据筛选的时候，前后筛选结果不具有可靠性。

　　在实际的数据库设计中，隔离级别越高，导致数据库的并发效率会越低；而隔离级别太低，又会导致数据库在读写过程中会遇到各种乱七八糟的问题。

　　因此在大多数数据库系统中，默认的隔离级别时读已提交（如Oracle）或者可重复读RR（MySQL的InnoDB引擎）。

　　MVCC的特点就是在同一时刻，不同事务可以读取到不同版本的数据，从而可以解决脏读和不可重复读的问题。

　　MVCC实际上就是通过数据的隐藏列和回滚日志（undo log），实现多个版本数据的共存。这样的好处是，使用MVCC进行读数据的时候，不用加锁，从而避免了同时读写的冲突。

　　在实现MVCC时，每一行的数据中会额外保存几个隐藏的列，比如当前行创建时的版本号和删除时间和指向undo log的回滚指针。这里的版本号并不是实际的时间值，而是系统版本号。每开始新的事务，系统版本号都会自动递增。事务开始时的系统版本号会作为事务的版本号，用来和查询每行记录的版本号进行比较。

　　每个事务又有自己的版本号，这样事务内执行数据操作时，就通过版本号的比较来达到数据版本控制的目的。

　　另外，InnoDB实现的隔离级别RR时可以避免幻读现象的，这是通过next-key lock机制实现的。这里简单讲讲吧。

　　next-key lock实际上就是行锁的一种，只不过它不只是会锁住当前行记录的本身，还会锁定一个范围。比如上面幻读的例子，开始查询0阅读量100的文章时，只查到了一个结果。next-key lock会将查询出的这一行进行锁定，同时还会对0阅读量100这个范围进行加锁，这实际上是一种间隙锁。间隙锁能够防止其他事务在这个间隙修改或者插入记录。这样一来，就保证了在0阅读量100这个间隙中，只存在原来的一行数据，从而避免了幻读。

　　虽然InnoDB使用next-key lock能够避免幻读问题，但却并不是真正的可串行化隔离。再来看一个例子吧。

　　答案是，文章AB的阅读量都被修改成了10000。这代表着事务B的提交实际上对事务A的执行产生了影响，表明两个事务之间并不是完全隔离的。虽然能够避免幻读现象，但是却没有达到可串行化的级别。

　　这还说明，避免脏读、不可重复读和幻读，是达到可串行化的隔离级别的必要不充分条件。可串行化是都能够避免脏读、不可重复读和幻读，但是避免脏读、不可重复读和幻读却不一定达到了可串行化。

　　一致性是事务追求的最终目标：前面提到的原子性、持久性和隔离性，都是为了保证数据库状态的一致性。

　　了解完MySQL的基本架构，大体上能够对MySQL的执行流程有了比较清晰的认知。接下来我将在讲述MySQL事务之前，先为大家介绍以下日志系统，以方便之后更好的理解事务的特性和实现。

　　MySQL日志系统是数据库的重要组件，用于记录数据库的更新和修改。若数据库发生故障，可通过不同日志记录恢复数据库的原来数据。因此实际上日志系统直接决定着MySQL运行的鲁棒性和稳健性。

　　MySQL的日志有很多种，如二进制日志（binlog）、错误日志、查询日志、慢查询日志等，此外InnoDB存储引擎还提供了两种日志：redo log（重做日志）和undo log（回滚日志）。这里将重点针对InnoDB引擎，对重做日志、回滚日志和二进制日志这三种进行分析。

　　重做日志（redo log）是InnoDB引擎层的日志，用来记录事务操作引起数据的变化，记录的是数据页的物理修改。

　　重做日记的作用其实很好理解，我打个比方。数据库中数据的修改就好比你写的论文，万一哪天论文丢了怎么呢？以防这种不幸的发生，我们可以在写论文的时候，每一次修改都拿个小本本记录一下，记录什么时间对某一页进行了怎么样的修改。这就是重做日志。

　　InnoDB引擎对数据的更新，是先将更新记录写入redo log日志，然后会在系统空闲的时候或者是按照设定的更新策略再将日志中的内容更新到磁盘之中。这就是所谓的预写式技术（Write Ahead logging）。这种技术可以大大减少IO操作的频率，提升数据刷新的效率。

　　值得注意的是，redo log日志的大小是固定的，为了能够持续不断的对更新记录进行写入，在redo log日志中设置了两个标志位置，checkpoint和write_pos，分别表示记录擦除的位置和记录写入的位置。redo log日志的数据写入示意图可见下图。

　　当write_pos标志到了日志结尾时，会从结尾跳至日志头部进行重新循环写入。所以redo log的逻辑结构并不是线性的，而是可看作一个圆周运动。write_pos与checkpoint中间的空间可用于写入新数。