第19章 说过的话就一定要办到-redo日志

我们前面介绍 InnoDB 的记录行格式的时候说过，如果我们没有为某个表显式的定义主键，并且表中也没有定义 Unique 键，那么 InnoDB 会自动的为表添加一个称之为 row_id 的隐藏列作为主键。为这个 row_id 隐藏列赋值的方式如下：

这个 Max Row ID 属性占用的存储空间是 8 个字节，当某个事务向某个包含 row_id 隐藏列的表插入一条记录，并且为该记录分配的 row_id 值为 256 的倍数时，就会向系统表空间页号为 7 的页面的相应偏移量处写入 8 个字节的值。但是我们要知道，这个写入实际上是在 Buffer Pool 中完成的，我们需要为这个页面的修改记录一条 redo 日志，以便在系统奔溃后能将已经提交的该事务对该页面所做的修改恢复出来。这种情况下对页面的修改是极其简单的，redo 日志中只需要 记录一下在某个页面的某个偏移量处修改了几个字节的值，具体被修改的内容是什么就好了，设计 InnoDB 的大佬把这种极其简单的 redo 日志称之为 物理日志，并且根据在页面中写入数据的多少划分了几种不同的 redo 日志类型：

我们上面提到的 Max Row ID 属性实际占用 8 个字节的存储空间，所以在修改页面中的该属性时，会记录一条类型为 MLOG_8BYTE 的 redo 日志，MLOG_8BYTE 的 redo 日志结构如下所示：

其余 MLOG_1BYTE、MLOG_2BYTE、MLOG_4BYTE 类型的 redo 日志结构和 MLOG_8BYTE 的类似，只不过具体数据中包含对应个字节的数据罢了。MLOG_WRITE_STRING 类型的 redo 日志表示写入一串数据，但是因为不能确定写入的具体数据占用多少字节，所以需要在日志结构中添加一个 len 字段：

有时候执行一条语句会修改非常多的页面，包括系统数据页面和用户数据页面（用户数据指的就是聚簇索引和二级索引对应的 B+ 树）。以一条 INSERT 语句为例，它除了要向 B+ 树的页面中插入数据，也可能更新系统数据 Max Row ID 的值，不过对于我们用户来说，平时更关心的是语句对 B+ 树所做更新：

在语句执行过程中，INSERT 语句对所有页面的修改都得保存到 redo 日志中去。这句话说的比较轻巧，做起来可就比较麻烦了，比方说将记录插入到聚簇索引中时，如果定位到的叶子节点的剩余空间足够存储该记录时，那么只更新该叶子节点页面就好，那么只记录一条 MLOG_WRITE_STRING 类型的 redo 日志，表明在页面的某个偏移量处增加了哪些数据就好了么？那就 too young too naive 了～ 别忘了一个数据页中除了存储实际的记录之后，还有什么 File Header、Page Header、Page Directory 等等部分（在介绍数据页的章节有详细讲解），所以每往叶子节点代表的数据页里插入一条记录时，还有其他很多地方会跟着更新，比如说：

画一个简易的示意图就像是这样：

说了这么多，就是想表达：把一条记录插入到一个页面时需要更改的地方非常多。这时我们如果使用上面介绍的简单的物理 redo 日志来记录这些修改时，可以有两种解决方案：

正因为上述两种使用物理 redo 日志的方式来记录某个页面中做了哪些修改比较浪费，设计 InnoDB 的大佬本着勤俭节约的初心，提出了一些新的 redo 日志类型，比如：

这些类型的 redo 日志既包含 物理 层面的意思，也包含 逻辑 层面的意思，具体指：

大家看到这可能有些懵逼，我们还是以类型为 MLOG_COMP_REC_INSERT 这个代表插入一条使用紧凑行格式的记录时的 redo 日志为例来理解一下我们上面所说的 物理 层面和 逻辑 层面到底是什么意思。废话少说，直接看一下这个类型为 MLOG_COMP_REC_INSERT 的 redo 日志的结构（由于字段太多了，我们把它们竖着看效果好些）：

这个类型为 MLOG_COMP_REC_INSERT 的 redo 日志结构有几个地方需要大家注意：

我们前面在介绍索引的时候说过，在一个数据页里，不论是叶子节点还是非叶子节点，记录都是按照索引列从小到大的顺序排序的。对于二级索引来说，当索引列的值相同时，记录还需要按照主键值进行排序。图中 n_uniques 的值的含义是在一条记录中，需要几个字段的值才能确保记录的唯一性，这样当插入一条记录时就可以按照记录的前 n_uniques 个字段进行排序。对于聚簇索引来说，n_uniques 的值为主键的列数，对于其他二级索引来说，该值为 索引列数+主键 列数。这里需要注意的是，唯一二级索引的值可能为 NULL，所以该值仍然为 索引列数+主键 列数。

很显然这个类型为 MLOG_COMP_REC_INSERT 的 redo 日志并没有记录 PAGE_N_DIR_SLOTS 的值修改为了什么，PAGE_HEAP_TOP 的值修改为了什么，PAGE_N_HEAP 的值修改为了什么等等这些信息，而只是把在本页面中插入一条记录所有必备的要素记了下来，之后系统奔溃重启时，服务器会调用相关向某个页面插入一条记录的那个函数，而 redo 日志中的那些数据就可以被当成是调用这个函数所需的参数，在调用完该函数后，页面中的 PAGE_N_DIR_SLOTS、PAGE_HEAP_TOP、PAGE_N_HEAP 等等的值也就都被恢复到系统奔溃前的样子了。这就是所谓的 逻辑 日志的意思。

虽然上面说了一大堆关于 redo 日志格式的内容，但是如果你不是为了写一个解析 redo 日志的工具或者自己开发一套 redo 日志系统的话，那就没必要把 InnoDB 中的各种类型的 redo 日志格式都研究的透透的，没那个必要。上面我只是象征性的介绍了几种类型的 redo 日志格式，目的还是想让大家明白：redo 日志会把事务在执行过程中对数据库所做的所有修改都记录下来，在之后系统奔溃重启后可以把事务所做的任何修改都恢复出来。

语句在执行过程中可能修改若干个页面。比如我们前面说的一条 INSERT 语句可能修改系统表空间页号为 7 的页面的 Max Row ID 属性（当然也可能更新别的系统页面，只不过我们没有都列举出来而已），还会更新聚簇索引和二级索引对应 B+ 树中的页面。由于对这些页面的更改都发生在 Buffer Pool 中，所以在修改完页面之后，需要记录一下相应的 redo 日志。在执行语句的过程中产生的 redo 日志被设计 InnoDB 的大佬人为的划分成了若干个不可分割的组，比如：

怎么理解这个 不可分割 的意思呢？我们以向某个索引对应的 B+ 树插入一条记录为例，在向 B+ 树中插入这条记录之前，需要先定位到这条记录应该被插入到哪个叶子节点代表的数据页中，定位到具体的数据页之后，有两种可能的情况：

现在我们要插入一条键值为 10 的记录，很显然需要被插入到 页b 中，但是从图中也可以看出来，此时 页b 已经塞满了记录，没有更多的空闲空间来容纳这条新记录了，所以我们需要进行页面的分裂操作，就像这样：

如果作为内节点的 页a 的剩余空闲空间也不足以容纳增加一条 目录项记录，那需要继续做内节点 页a 的分裂操作，也就意味着会修改更多的页面，从而产生更多的 redo 日志。另外，对于 悲观插入 来说，由于需要新申请数据页，还需要改动一些系统页面，比方说要修改各种段、区的统计信息信息，各种链表的统计信息（比如什么 FREE 链表、FSP_FREE_FRAG 链表等等我们在介绍表空间那一章中介绍过的各种东东）等等等等，反正总共需要记录的 redo 日志有二、三十条。

设计 InnoDB 的大佬们认为向某个索引对应的 B+ 树中插入一条记录的这个过程必须是原子的，不能说插了一半之后就停止了。比方说在悲观插入过程中，新的页面已经分配好了，数据也复制过去了，新的记录也插入到页面中了，可是没有向内节点中插入一条目录项记录，这个插入过程就是不完整的，这样会形成一棵不正确的 B+ 树。我们知道 redo 日志是为了在系统奔溃重启时恢复崩溃前的状态，如果在悲观插入的过程中只记录了一部分 redo 日志，那么在系统奔溃重启时会将索引对应的 B+ 树恢复成一种不正确的状态，这是设计 InnoDB 的大佬们所不能忍受的。所以他们规定在执行这些需要保证原子性的操作时必须以组的形式来记录的 redo 日志，在进行系统奔溃重启恢复时，针对某个组中的 redo 日志，要么把全部的日志都恢复掉，要么一条也不恢复。怎么做到的呢？这得分情况讨论：

其实在一条日志后边跟一个类型为 MLOG_MULTI_REC_END 的 redo 日志也是可以的，不过设计 InnoDB 的大佬比较勤俭节约，他们不想浪费一个比特位。别忘了虽然 redo 日志的类型比较多，但撑死了也就是几十种，是小于 127 这个数字的，也就是说我们用 7 个比特位就足以包括所有的 redo 日志类型，而 type 字段其实是占用 1 个字节的，也就是说我们可以省出来一个比特位用来表示该需要保证原子性的操作只产生单一的一条 redo 日志，示意图如下：

如果 type 字段的第一个比特位为 1，代表该需要保证原子性的操作只产生了单一的一条 redo 日志，否则表示该需要保证原子性的操作产生了一系列的 redo 日志。

设计 MySQL 的大佬把对底层页面中的一次原子访问的过程称之为一个 Mini-Transaction，简称 mtr，比如上面所说的修改一次 Max Row ID 的值算是一个 Mini-Transaction，向某个索引对应的 B+ 树中插入一条记录的过程也算是一个 Mini-Transaction。通过上面的叙述我们也知道，一个所谓的 mtr 可以包含一组 redo 日志，在进行奔溃恢复时这一组 redo 日志作为一个不可分割的整体。

一个事务可以包含若干条语句，每一条语句其实是由若干个 mtr 组成，每一个 mtr 又可以包含若干条 redo 日志，画个图表示它们的关系就是这样：

设计 InnoDB 的大佬为了更好的进行系统奔溃恢复，他们把通过 mtr 生成的 redo 日志都放在了大小为 512字节 的 页 中。为了和我们前面提到的表空间中的页做区别，我们这里把用来存储 redo 日志的页称为 block（你心里清楚页和 block 的意思其实差不多就行了）。一个 redo log block 的示意图如下：

真正的 redo 日志都是存储到占用 496 字节大小的 log block body 中，图中的 log block header 和 log block trailer 存储的是一些管理信息。我们来看看这些所谓的管理信息都是什么：

其中 log block header 的几个属性的意思分别如下：

log block trailer 中属性的意思如下：

我们前面说过，设计 InnoDB 的大佬为了解决磁盘速度过慢的问题而引入了 Buffer Pool。同理，写入 redo 日志时也不能直接写到磁盘上，实际上在服务器启动时就向操作系统申请了一大片称之为 redo log buffer 的连续内存空间，翻译成中文就是 redo 日志缓冲区，我们也可以简称为 log buffer。这片内存空间被划分成若干个连续的 redo log block，就像这样：

我们可以通过启动参数 innodb_log_buffer_size 来指定 log buffer 的大小，在 MySQL 5.7.21 这个版本中，该启动参数的默认值为 16MB。

向 log buffer 中写入 redo 日志的过程是顺序的，也就是先往前面的 block 中写，当该 block 的空闲空间用完之后再往下一个 block 中写。当我们想往 log buffer 中写入 redo 日志时，第一个遇到的问题就是应该写在哪个 block 的哪个偏移量处，所以设计 InnoDB 的大佬特意提供了一个称之为 buf_free 的全局变量，该变量指明后续写入的 redo 日志应该写入到 log buffer 中的哪个位置，如图所示：

我们前面说过一个 mtr 执行过程中可能产生若干条 redo 日志，这些 redo 日志是一个不可分割的组，所以其实并不是每生成一条 redo 日志，就将其插入到 log buffer 中，而是每个 mtr 运行过程中产生的日志先暂时存到一个地方，当该 mtr 结束的时候，将过程中产生的一组 redo 日志再全部复制到 log buffer 中。我们现在假设有两个名为 T1、T2 的事务，每个事务都包含 2 个 mtr，我们给这几个 mtr 命名一下：

每个 mtr 都会产生一组 redo 日志，用示意图来描述一下这些 mtr 产生的日志情况：

不同的事务可能是并发执行的，所以 T1、T2 之间的 mtr 可能是交替执行的。每当一个 mtr 执行完成时，伴随该 mtr 生成的一组 redo 日志就需要被复制到 log buffer 中，也就是说不同事务的 mtr 可能是交替写入 log buffer 的，我们画个示意图（为了美观，我们把一个 mtr 中产生的所有的 redo 日志当作一个整体来画）：

从示意图中我们可以看出来，不同的 mtr 产生的一组 redo 日志占用的存储空间可能不一样，有的 mtr 产生的 redo 日志量很少，比如 mtr_t1_1、mtr_t2_1 就被放到同一个 block 中存储，有的 mtr 产生的 redo 日志量非常大，比如 mtr_t1_2 产生的 redo 日志甚至占用了 3 个 block 来存储。

我们前面说 mtr 运行过程中产生的一组 redo 日志在 mtr 结束时会被复制到 log buffer 中，可是这些日志总在内存里呆着也不是个办法，在一些情况下它们会被刷新到磁盘里，比如：

MySQL 的数据目录（使用 SHOW VARIABLES LIKE 'datadir' 查看）下默认有两个名为 ib_logfile0 和 ib_logfile1 的文件，log buffer 中的日志默认情况下就是刷新到这两个磁盘文件中。如果我们对默认的 redo 日志文件不满意，可以通过下面几个启动参数来调节：

从上面的描述中可以看到，磁盘上的 redo 日志文件不只一个，而是以一个 日志文件组 的形式出现的。这些文件以 ib_logfile[数字]（数字 可以是 0、1、2…​）的形式进行命名。在将 redo 日志写入 日志文件组 时，是从 ib_logfile0 开始写，如果 ib_logfile0 写满了，就接着 ib_logfile1 写，同理，ib_logfile1 写满了就去写 ib_logfile2，依此类推。如果写到最后一个文件该咋办？那就重新转到 ib_logfile0 继续写，所以整个过程如下图所示：

总共的 redo 日志文件大小其实就是： innodb_log_file_size × innodb_log_files_in_group。

我们前面说过 log buffer 本质上是一片连续的内存空间，被划分成了若干个 512 字节大小的 block。将 log buffer 中的 redo 日志刷新到磁盘的本质就是把 block 的镜像写入日志文件中，所以 redo 日志文件其实也是由若干个 512 字节大小的 block 组成。

redo 日志文件组中的每个文件大小都一样，格式也一样，都是由两部分组成：

所以我们前面所说的 循环 使用 redo 日志文件，其实是从每个日志文件的第 2048 个字节开始算，画个示意图就是这样：

普通 block 的格式我们在介绍 log buffer 的时候都说过了，就是 log block header、log block body、log block trialer 这三个部分，就不重复介绍了。这里需要介绍一下每个 redo 日志文件前 2048 个字节，也就是前 4 个特殊 block 的格式都是干嘛的，废话少说，先看图：

从图中可以看出来，这 4 个 block 分别是：

redo 日志是首先写到 log buffer 中，之后才会被刷新到磁盘上的 redo 日志文件。所以设计 InnoDB 的大佬提出了一个称之为 buf_next_to_write 的全局变量，标记当前 log buffer 中已经有哪些日志被刷新到磁盘中了。画个图表示就是这样：

我们前面说 lsn 是表示当前系统中写入的 redo 日志量，这包括了写到 log buffer 而没有刷新到磁盘的日志，相应的，设计 InnoDB 的大佬提出了一个表示刷新到磁盘中的 redo 日志量的全局变量，称之为 flushed_to_disk_lsn。系统第一次启动时，该变量的值和初始的 lsn 值是相同的，都是 8704。随着系统的运行，redo 日志被不断写入 log buffer，但是并不会立即刷新到磁盘，lsn 的值就和 flushed_to_disk_lsn 的值拉开了差距。我们演示一下：

综上所述，当有新的 redo 日志写入到 log buffer 时，首先 lsn 的值会增长，但 flushed_to_disk_lsn 不变，随后随着不断有 log buffer 中的日志被刷新到磁盘上，flushed_to_disk_lsn 的值也跟着增长。如果两者的值相同时，说明 log buffer 中的所有 redo 日志都已经刷新到磁盘中了。

因为 lsn 的值是代表系统写入的 redo 日志量的一个总和，一个 mtr 中产生多少日志，lsn 的值就增加多少（当然有时候要加上 log block header 和 log block trailer 的大小），这样 mtr 产生的日志写到磁盘中时，很容易计算某一个 lsn 值在 redo 日志文件组中的偏移量，如图：

初始时的 LSN 值是 8704，对应文件偏移量 2048，之后每个 mtr 向磁盘中写入多少字节日志，lsn 的值就增长多少。

我们知道一个 mtr 代表一次对底层页面的原子访问，在访问过程中可能会产生一组不可分割的 redo 日志，在 mtr 结束时，会把这一组 redo 日志写入到 log buffer 中。除此之外，在 mtr 结束时还有一件非常重要的事情要做，就是 把在 mtr 执行过程中可能修改过的页面加入到 Buffer Pool 的 flush 链表。为了防止大家早已忘记 flush 链表 是什么，我们再看一下图：

当第一次修改某个缓存在 Buffer Pool 中的页面时，就会把这个页面对应的控制块插入到 flush 链表 的头部，之后再修改该页面时由于它已经在 flush 链表中了，就不再次插入了。也就是说 flush 链表中的脏页是按照页面的第一次修改时间从大到小进行排序的。在这个过程中会在缓存页对应的控制块中记录两个关于页面何时修改的属性：

我们接着上面介绍 flushed_to_disk_lsn 的例子看一下：

总结一下上面说的，就是：flush 链表中的脏页按照修改发生的时间顺序进行排序，也就是按照 oldest_modification 代表的 LSN 值进行排序，被多次更新的页面不会重复插入到 flush 链表中，但是会更新 newest_modification 属性的值。

我们在介绍 Buffer Pool 的时候说过，一般情况下都是后台的线程在对 LRU 链表 和 flush 链表 进行刷脏操作，这主要因为刷脏操作比较慢，不想影响用户线程处理请求。但是如果当前系统修改页面的操作十分频繁，这样就导致写日志操作十分频繁，系统 lsn 值增长过快。如果后台的刷脏操作不能将脏页刷出，那么系统无法及时做 checkpoint，可能就需要用户线程同步的从 flush 链表 中把那些最早修改的脏页（oldest_modification 最小的脏页）刷新到磁盘，这样这些脏页对应的 redo 日志就没用了，然后就可以去做 checkpoint 了。

我们可以使用 SHOW ENGINE INNODB STATUS 命令查看当前 InnoDB 存储引擎中的各种 LSN 值的情况，比如：

其中：

我们前面说过，checkpoint_lsn 之前的 redo 日志都可以被覆盖，也就是说这些 redo 日志对应的脏页都已经被刷新到磁盘中了，既然它们已经被刷盘，我们就没必要恢复它们了。对于 checkpoint_lsn 之后的 redo 日志，它们对应的脏页可能没被刷盘，也可能被刷盘了，我们不能确定，所以需要从 checkpoint_lsn 开始读取 redo 日志来恢复页面。

当然，redo 日志文件组的第一个文件的管理信息中有两个 block 都存储了 checkpoint_lsn 的信息，我们当然是要选取 最近发生的那次 checkpoint 的信息。衡量 checkpoint 发生时间早晚的信息就是所谓的checkpoint_no，我们只要把 checkpoint1 和 checkpoint2 这两个 block 中的 checkpoint_no 值读出来比一下大小，哪个的 checkpoint_no 值更大，说明哪个 block 存储的就是最近的一次 checkpoint 信息。这样我们就能拿到最近发生的 checkpoint 对应的 checkpoint_lsn 值以及它在 redo 日志文件组中的偏移量 checkpoint_offset。

redo 日志恢复的起点确定了，那终点是哪个呢？这个还得从 block 的结构说起。我们说在写 redo 日志的时候都是顺序写的，写满了一个 block 之后会再往下一个 block 中写：

普通 block 的 log block header 部分有一个称之为 LOG_BLOCK_HDR_DATA_LEN 的属性，该属性值记录了当前 block 里使用了多少字节的空间。对于被填满的 block 来说，该值永远为 512。如果该属性的值不为 512，那么就是它了，它就是此次奔溃恢复中需要扫描的最后一个 block。

确定了需要扫描哪些 redo 日志进行奔溃恢复之后，接下来就是怎么进行恢复了。假设现在的 redo 日志文件中有 5 条 redo 日志，如图：

由于 redo 0 在 checkpoint_lsn 后边，恢复时可以不管它。我们现在可以按照 redo 日志的顺序依次扫描 checkpoint_lsn 之后的各条 redo 日志，按照日志中记载的内容将对应的页面恢复出来。这样没什么问题，不过设计 InnoDB 的大佬还是想了一些办法加快这个恢复的过程：