1、前言

狼哥一直对数据库Mysql这块没有进行过系统的深入学习，今天看到一篇文章写的还不错，特意分享一下，我不能保证文章中所讲的都是正确，大家都应该带着探索的思维去阅读别人的文章。

数据库的4大事务特性ACID，想必大家都应该知道。

ACID表示原子性、一致性、隔离性和持久性。一个很好的事务处理系统，必须具备这些标准特性：

• 原子性（Atomicity）：一个事务必须被视为一个不可分割的最小工作单元，整个事务中的所有操作要么全部提交成功，要么全部失败回滚。

• 一致性（consistency）：数据库总是从一个一致性的状态转换到另一个一致性的状态。（其实原子性和隔离性间接的保证了一致性）

• 隔离性（isolation）：通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。

• 持久性（durability）：一旦事务提交，则其所做的修改就会永久保存到数据库中。

而我们最常说的隔离性其实有对应的隔离级别，MySQL规定的隔离级别有4种，分别是：

• READ UNCOMMITTED（读未提交）：在此级别里，事务的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，也就是会产生脏读，在实际应用中一般很少使用。

• READ COMMITTED（读已提交）：大多数数据库系统的默认隔离级别都是它，但是MySQL不是。它能够避免脏读问题，但是在一个事务里对同一条数据的多次查询可能会得到不同的结果，也就是会产生不可重复读问题。

• REPEATABLE READ（可重复读）：该隔离级别是MySQL默认的隔离级别，看名字就知道它能够防止不可重复读问题，但是在一个事务里对一段数据的多次读取可能会导致不同的结果，也就是会有幻读的问题（注：这里说的无法解决是MySQL定义层面，对于InnoDB引擎则完美的解决了幻读的问题，如果你正在使用InnoDB引擎，可忽略）

• SERIALIZABLE（可串行化）：该隔离级别是级别最高的，它通过锁来强制事务串行执行，避免了前面说的所有问题。在高并发下，可能导致大量的超时和锁争用问题。实际应用中也很少用到这个隔离级别，因为RR级别解决了所有问题。

可以看到隔离级别里最重要的只有两个隔离级别：RC和RR。那么问题来了，我们知道上面说的ACID以及隔离级别的实现原理吗？无论是平时工作还是面试，这部分的问题都重中之重，接下来，我会抛出几个问题，大家可以带着问题来看此文：

ACID问题：

• InnoDB能够保证原子性？用的什么方式？
• 为什么InnoDB能够保证一致性？用的什么方式？
• 为什么InnoDB能够保证持久性？用的什么方式？

隔离性里隔离级别的问题：

为什么RU级别会发生脏读，而其他的隔离级别能够避免？ 为什么RC级别不能重复读，而RR级别能够避免？ 为什么InnoDB的RR级别能够防止幻读？ 解决这些问题之前，我们要首先知道Redo log、Undo log以及MVCC都是什么。

2、Redo log

redo log（重做日志）用来实现事务的持久性，即事务ACID中的D。其由两部分组成，一是内存中的重做日志缓冲（redo log buffer），其实易失的。二是重做日志文件（redo log file），其是持久的。

在一个事务中的每一次SQL操作之后都会写入一个redo log到buffer中，在最后COMMIT的时候，必须先将该事务的所有日志写入到redo log file进行持久化（这里的写入是顺序写的），待事务的COMMIT操作完成才算完成。

由于重做日志文件打开没有使用O_DIRECT选项，因此重做日志缓冲先写入文件系统缓存。为了确保重做日志写入磁盘，必须进行一次fsync操作。由于fsync的效率取决于磁盘的性能，因此磁盘的性能决定了事务提交的性能，也就是数据库的性能。由此我们可以得出在进行批量操作的时候，不要for循环里面嵌套事务。

参数 innodb_flush_log_at_trx_commit 用来控制重做日志刷新到磁盘的策略，该参数有3个值：0、1和2。

• 0：表示事务提交时不进行写redo log file的操作，这个操作仅在master thread中完成（master thread每隔1秒进行一次fsync操作）。

• 1：默认值，表示每次事务提交时进行写redo log file的操作。

• 2：表示事务提交时将redo log写入文件，不过仅写入文件系统的缓存中，不进行fsync操作。

我们可以看到0和2的设置都比1的效率要高，但是破坏了数据库的ACID特性，不建议使用！

对比binlog

在MySQL数据库中还有一种二进制日志（binlog），从表面上来看它和redo log很相似，都是记录了对数据库操作的日志，但是，它们有着非常大的不同。

首先，redo log是在MySQL的InnoDB引擎层产生，而binlog则是在MySQL的上层产生，它不仅针对InnoDB引擎，其他任何引擎对于数据库的更改都会产生binlog。

其次，两种日志记录的内容形式不同，binlog是一种逻辑日志，其记录的是对应的SQL语句。而redo log则是记录的物理格式日志，其记录的是对于每个页的修改。

此外，两种日志记录写入磁盘的时间点不同，binlog只在事务提交完成后一次性写入，而redo log在上面也说了是在事务进行中不断被写入，这表现为日志并不是随事务提交的顺序进行写入的。

redo log block

在InnoDB引擎中，redo log都是以512字节进行存储的（和磁盘扇区的大小一样，因此redo log写入可以保证原子性，不需要double write），也就是重做日志缓存和文件都是以块的方式进行保存的，称为redo log block，每个block占512字节。

重做日志除了日志本身之外，还由日志块头（log block header）及日志块尾（log block tailer）两部分组成。

下面我来解释一下组成Log Block header的4个部分各自的含义： LOGBLOCKHDR_NO：它主要用来标记所处Redo Log Buffer中Log Block的位置。 LOGBLOCKHDRDATALEN：它表示Log Block所占用的大小。当Log Block被写满时，该值为0x200，表示使用全部Log Block空间，即占用512字节。 LOGBLOCKFIRSTRECGROUP：表示Log Block中第一个日志所在的偏移量，如果该值大小和LOGBLOCKHDRDATALEN相同，则表示当前Log Block不包含新的日志，如果事务的日志大小超过一个Log Block的大小，剩余的将会接着保存到一个新的Log Block中。 LOGBLOCKCHECKPOINT_NO：表示该Log Block最后被写入时的检查点第4字节的值。 Log Block tailer只包含一个LOGBLOCKTRLNO，它的值和LOGBLOCKHDRNO相同，并在函数logblockinit中被初始化。

crash recovery

前面提到了redo log是用来实现ACID的持久性的，也就是只要事务提交成功后，事务内的所有修改都会保存到数据库，哪怕这时候数据库crash了，也要有办法来进行恢复。也就是Crash Recovery。

说到恢复，我们先来了解一个概念：什么是LSN？

LSN(log sequence number) 用于记录日志序号，它是一个不断递增的 unsigned long long 类型整数，占用8字节。它代表的含义有：

redo log写入的总量。 checkpoint的位置。 页的版本，用来判断是否需要进行恢复操作。 checkpoint：它是redo log中的一个检查点，这个点之前的所有数据都已经刷新回磁盘，当DB crash后，通过对checkpoint之后的redo log进行恢复就可以了。 我们可以通过命令show engine innodb status来观察LSN的情况：

---

LOG

Log sequence number 33646077360 Log flushed up to

33646077360 Last checkpoint at 33646077360 0 pending log writes ,

0 pending chkp writes 49687445 log i / o 's done, 1.25 log i/o' s / second

Log sequence number表示当前的LSN，Log flushed up to表示刷新到redo log文件的LSN，Last checkpoint at表示刷新到磁盘的LSN。如果把它们三个简写为 A、B、C 的话，它们的值的大小肯定为 A>=B>=C。

InnoDB引擎在启动时不管上次数据库运行时是否正常关闭，都会进行恢复操作。因为重做日志记录的是物理日志，因此恢复的速度比逻辑日志，如二进制日志要快很多。恢复的时候只需要找到redo log的checkpoint进行恢复即可。

3、Undo log

重做日志记录了事务的行为，可以很好的通过其对页进行“重做”操作。但是事务有时候还需要进行回滚操作，也就是ACID中的A（原子性），这时就需要Undo log了。因此在数据库进行修改时，InnoDB存储引擎不但会产生Redo，还会产生一定量的Undo。这样如果用户执行的事务或语句由于某种原因失败了，又或者用户一条ROLLBACK语句请求回滚，就可以利用这些Undo信息将数据库回滚到修改之前的样子。

Undo log是InnoDB MVCC事务特性的重要组成部分。当我们对记录做了变更操作时就会产生Undo记录，Undo记录默认被记录到系统表空间(ibdata)中，但从5.6开始，也可以使用独立的Undo 表空间。

Undo记录中存储的是老版本数据，当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着undo链找到满足其可见性的记录。当版本链很长时，通常可以认为这是个比较耗时的操作。

基本文件结构

为了保证事务并发操作时，在写各自的undo log时不产生冲突，InnoDB采用回滚段（Rollback Segment，简称Rseg）的方式来维护undo log的并发写入和持久化。回滚段实际上是一种 Undo 文件组织方式，每个回滚段又有多个undo log slot。具体的文件组织方式如下图所示：

上图展示了基本的Undo回滚段布局结构，其中: rseg0预留在系统表空间ibdata中。 rseg 1~rseg 32 这32个回滚段存放于临时表的系统表空间中，用于临时表的undo。 rseg33~rseg 128 则根据配置（InnoDB >= 1.1默认128，可通过参数 innodb_undo_logs 设置）存放到独立undo表空间中（如果没有打开独立Undo表空间，则存放于ibdata中，独立表空间可以通过参数 innodb_undo_directory 设置），用于普通事务的undo。 如图所示，每个回滚段维护了一个段头页，在该page中又划分了1024个slot(TRXRSEGN_SLOTS)，每个slot又对应到一个undo log对象，因此理论上InnoDB最多支持 96 * 1024个普通事务。

Undo log的格式

在InnoDB引擎中，undo log分为：

insert undo log update undo log insert undo log是指在insert操作中产生的undo log，因为insert操作的记录，只对事务本身可见，对其他事务不可见（这是事务隔离性的要求），故该undo log可以在事务提交后直接删除，不需要进行purge操作。而update undo log记录的是delete和update操作产生的undo log。该undo log可能需要提供MVCC机制，因此不能在事务提交时就进行删除，提交时放入undo log链表，等待purge线程进行最后的删除。下面是两种undo log的结构图。

purge

对于一条delete语句 deletefromtwherea=1，如果列a有聚集索引，则不会进行真正的删除，而只是在主键列等于1的记录delete flag设置为1，即记录还是存在在B+树中。而对于update操作，不是直接对记录进行更新，而是标识旧记录为删除状态，然后新产生一条记录。那这些旧版本标识位删除的记录何时真正的删除？怎么删除？

其实InnoDB是通过undo日志来进行旧版本的删除操作的，在InnoDB内部，这个操作被称之为purge操作，原来在srvmasterthread主线程中完成，后来进行优化，开辟了purge线程进行purge操作，并且可以设置purge线程的数量。purge操作每10s进行一次。

为了节省存储空间，InnoDB存储引擎的undo log设计是这样的：一个页上允许多个事务的undo log存在。虽然这不代表事务在全局过程中提交的顺序，但是后面的事务产生的undo log总在最后。此外，InnoDB存储引擎还有一个history列表，它根据事务提交的顺序，将undo log进行连接，如下面的一种情况：

在执行purge过程中，InnoDB存储引擎首先从history list中找到第一个需要被清理的记录，这里为trx1，清理之后InnoDB存储引擎会在trx1所在的Undo page中继续寻找是否存在可以被清理的记录，这里会找到事务trx3，接着找到trx5，但是发现trx5被其他事务所引用而不能清理，故再去history list中取查找，发现最尾端的记录时trx2，接着找到trx2所在的Undo page，依次把trx6、trx4清理，由于Undo page2中所有的记录都被清理了，因此该Undo page可以进行重用。 InnoDB存储引擎这种先从history list中找undo log，然后再从Undo page中找undo log的设计模式是为了避免大量随机读操作，从而提高purge的效率。

4、多版本控制MVCC MVCC 多版本并发控制技术,用于多事务环境下,对数据读写在不加读写锁的情况下实现互不干扰,从而实现数据库的隔离性,在事务隔离级别为Read Commit 和 Repeatable Read中使用到，今天我们就用最简单的方式，来分析下MVCC具体的原理，先解释几个概念。

InnoDB存储引擎的行结构

InnoDB表数据的组织方式为主键聚簇索引，二级索引中采用的是(索引键值, 主键键值)的组合来唯一确定一条记录。

InnoDB表数据为主键聚簇索引,mysql默认为每个索引行添加了4个隐藏的字段,分别是：

DBROWID：InnoDB引擎中一个表只能有一个主键,用于聚簇索引,如果表没有定义主键会选择第一个非Null的唯一索引作为主键,如果还没有,生成一个隐藏的DBROWID作为主键构造聚簇索引。 DBTRXID：最近更改该行数据的事务ID。 DBROLLPTR：undo log的指针,用于记录之前历史数据在undo log中的位置。 DELETE BIT：索引删除标志,如果DB删除了一条数据,是优先通知索引将该标志位设置为1,然后通过(purge)清除线程去异步删除真实的数据。

整个MVCC的机制都是通过 DB_TRX_ID, DB_ROLL_PTR这2个隐藏字段来实现的。

事务链表

当一个事务开始的时候,会将当前数据库中正在活跃的所有事务(执行begin,但是还没有commit的事务)保存到一个叫 trx_sys的事务链表中,事务链表中保存的都是未提交的事务,当事务提交之后会从其中删除。