MySQL 事务的持久性 详解MySQL中事务的持久性实现原理

前言

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

在之前的文章我们已经了解了MySQL中事务的隔离性的实现原理，今天就继续来聊一聊MySQL持久性的实现原理。

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

说明

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

InnoDB读写数据原理

在往下学习之前，我们需要先来了解下InnoDB是怎么来读写数据的。我们知道数据库的数据都是存放在磁盘中的，然后我们也知道磁盘I/O的成本是很大的，如果每次读写数据都要访问磁盘，数据库的效率就会非常低。为了解决这个问题，InnoDB提供了 Buffer Pool 作为访问数据库数据的缓冲。

Buffer Pool 是位于内存的，包含了磁盘中部分数据页的映射。当需要读取数据时，InnoDB会首先尝试从Buffer Pool中读取，读取不到的话就会从磁盘读取后放入Buffer Pool；当写入数据时，会先写入Buffer Pool的页面，并把这样的页面标记为dirty，并放到专门的flush list上，这些修改的数据页会在后续某个时刻被刷新到磁盘中（这一过程称为刷脏，由其他后台线程负责） 。如下图所示：

这样设计的好处是可以把大量的磁盘I/O转成内存读写，并且把对一个页面的多次修改merge成一次I/O操作（刷脏一次刷入整个页面），避免每次读写操作都访问磁盘，从而大大提升了数据库的性能。

持久性定义

持久性是指事务一旦提交，它对数据库的改变就应该是永久性的，接下来的其他操作或故障不应该对本次事务的修改有任何影响。

通过前面的介绍，我们知道InnoDB使用 Buffer Pool  来提高读写的性能。但是 Buffer Pool 是在内存的，是易失性的，如果一个事务提交了事务后，MySQL突然宕机，且此时Buffer Pool中修改的数据还没有刷新到磁盘中的话，就会导致数据的丢失，事务的持久性就无法保证。

为了解决这个问题，InnoDB引入了 redo log来实现数据修改的持久化。当数据修改时，InnoDB除了修改Buffer Pool中的数据，还会在redo log 记录这次操作，并保证redo log早于对应的页面落盘（一般在事务提交的时候），也就是常说的WAL。若MySQL突然宕机了且还没有把数据刷回磁盘，重启后，MySQL会通过已经写入磁盘的redo log来恢复没有被刷新到磁盘的数据页。

实现原理：redo log

为了提高性能，和数据页类似，redo log 也包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的。redo log是物理日志，记录的是数据库中物理页的情况 。

当数据发生修改时，InnoDB不仅会修改Buffer Pool中的数据，也会在redo log buffer记录这次操作；当事务提交时，会对redo log buffer进行刷盘，记录到redo log file中。如果MySQL宕机，重启时可以读取redo log file中的数据，对数据库进行恢复。这样就不需要每次提交事务都实时进行刷脏了。

写入过程

注意点：

• 先修改Buffer Pool，后写 redo log buffer。
• redo日志比数据页先写回磁盘：事务提交的时候，会把redo log buffer写入redo log file，写入成功才算提交成功（也有其他场景触发写入，这里就不展开了），而Buffer Pool的数据由后台线程在后续某个时刻写入磁盘。
• 刷脏的时候一定会保证对应的redo log已经落盘了，也即是所谓的WAL（预写式日志），否则会有数据丢失的可能性。
  

好处

事务提交的时候，写入redo log 相比于直接刷脏的好处主要有三点：

刷脏是随机I/O，但写redo log 是顺序I/O，顺序I/O可比随机I/O快多了，不需要。
刷脏是以数据页（Page）为单位的，即使一个Page只有一点点修改也要整页写入；而redo log中只包含真正被修改的部分，数据量非常小，无效IO大大减少。
刷脏的时候可能要刷很多页的数据，无法保证原子性（例如只写了一部分数据就失败了），而redo log buffer 向 redo log file 写log block，是按512个字节，也就是一个扇区的大小进行写入，扇区是写入的最小单位，因此可以保证写入是必定成功的。

先写redo log还是先修改数据

一次DML可能涉及到数据的修改和redo log的记录，那它们的执行顺序是怎么样的呢？网上的文章有的说先修改数据，后记录redo log，有的说先记录redo log，后改数据，那真实的情况是如何呢？

首先通过上面的说明我们知道，redo log buffer在事务提交的时候就会写入redo log file的，而刷脏则是在后续的某个时刻，所以可以确定的是先记录redo log，后修改data page（WAL当然是日志先写啦）。

那接下来的问题就是先写redo log buffer还是先修改Buffer Pool了。要了解这个问题，我们先要了解InnoDB中，一次DML的执行过程是怎么样的。一次DML的执行过程涉及了数据的修改，加锁，解锁，redo log的记录和undo log的记录等，也是需要保证原子性的，而InnoDB通过MTR(Mini-transactions)来保证一次DML操作的原子性。

首先来看MTR的定义:

 An internal phase of InnoDB processing, when making changes at the physical level to internal data structures during DML operations. A Mini-transactions (mtr) has no notion of rollback; multiple Mini-transactionss can occur within a single transaction. Mini-transactionss write information to the redo log that is used during crash recovery. A Mini-transactions can also happen outside the context of a regular transaction, for example during purge processing by background threads. 见 https://dev.mysql.com/doc/refman/8.0/en/glossary.html

MTR 是一个短原子操作，不能回滚，因为它本身就是原子的。数据页的变更必须通过MTR，MTR 会把DML操作对数据页的修改记录到 redo log里。

下面来简单看下MTR的过程：

• MTR初始化的时候会初始化一份 mtr_buf
• 当修改数据时，在对内存Buffer Pool中的页面进行修改的同时，还会生成redo log record，保存在mtr_buf中。
• 在执行mtr_commit函数提交本MTR的时候，会将mtr_buf中的redo log record更新到redo log buffer中，同时将脏页添加到flush list，供后续刷脏使用。在log buffer中，每接收到496字节的log record，就将这组log record包装一个12字节的block header和一个4字节的block tailer，成为一个512字节的log block，方便刷盘的时候对齐512字节刷盘。
  

由此可见，InnoDB是先修改Buffer Pool，后写redo log buffer的。

恢复数据的过程

在任何情况下，InnoDB启动时都会尝试执行recovery操作。在恢复过程中，需要redo log参与，而如果还开启了binlog，那就还需要binlog、undo log的参与。因为有可能数据已经写入binlog了，但是redo log还没有刷盘的时候数据库就奔溃了（事务是InnoDB引擎的特性，修改了数据不一定提交了，而binlog是MySQL服务层的特性，修改数据就会记录了），这时候就需要redo log，binlog和undo log三者的参与来判断是否有还没提交的事务，未提交的事务进行回滚或者提交操作。

下面来简单说下仅利用redo log恢复数据的过程：

• 启动InnoDB时，找到最近一次Checkpoint的位置，利用Checkpoint LSN去找大于该LSN的redo log进行日志恢复。
• 如果中间恢复失败了也没影响，再次恢复的时候还是从上次保存成功的Checkpoint的位置继续恢复。
  

Recover过程：故障恢复包含三个阶段：Analysis，Redo和Undo。Analysis阶段的任务主要是利用Checkpoint及Log中的信息确认后续Redo和Undo阶段的操作范围，通过Log修正Checkpoint中记录的Dirty Page集合信息，并用其中涉及最小的LSN位置作为下一步Redo的开始位置RedoLSN。同时修正Checkpoint中记录的活跃事务集合（未提交事务），作为Undo过程的回滚对象；Redo阶段从Analysis获得的RedoLSN出发，重放所有的Log中的Redo内容，注意这里也包含了未Commit事务；最后Undo阶段对所有未提交事务利用Undo信息进行回滚，通过Log的PrevLSN可以顺序找到事务所有需要回滚的修改。具体见 http://catkang.github.io/2019/01/16/crash-recovery.html

什么是LSN?

LSN也就是log sequence number，也日志的序列号，是一个单调递增的64位无符号整数。redo log和数据页都保存着LSN，可以用作数据恢复的依据。LSN更大的表示所引用的日志记录所描述的变化发生在更后面。

什么是Checkpoint？

Checkpoint表示一个保存点，在这个点之前的数据页的修改（log LSN<Checkpoint LSN）都已经写入磁盘文件了。InnoDB每次刷盘之后都会记录Checkpoint，把最新的redo log LSN 记录到Checkpoint LSN 里，方便恢复数据的时候作为起始点的判断。