第21章 后悔了怎么办-undo日志

我们前面在介绍 事务简介 时说过，一个事务可以是一个只读事务，或者是一个读写事务：

在读写事务中可以对表执行增删改查操作。

如果某个事务执行过程中对某个表执行了增、删、改操作，那么 InnoDB 存储引擎就会给它分配一个独一无二的 事务 id，分配方式如下：

这个 事务 id 本质上就是一个数字，它的分配策略和我们前面提到的对隐藏列 row_id（当用户没有为表创建主键和 UNIQUE 键时 InnoDB 自动创建的列）的分配策略大抵相同，具体策略如下：

我们前面介绍 InnoDB 记录行格式的时候重点强调过：聚簇索引的记录除了会保存完整的用户数据以外，而且还会自动添加名为 trx_id、roll_pointer 的隐藏列，如果用户没有在表中定义主键以及 UNIQUE 键，还会自动添加一个名为 row_id 的隐藏列。所以一条记录在页面中的真实结构看起来就是这样的：

其中的 trx_id 列其实还蛮好理解的，就是某个对这个聚簇索引记录做改动的语句所在的事务对应的 事务id 而已（此处的改动可以是 INSERT、DELETE、UPDATE 操作）。至于 roll_pointer 隐藏列我们后边分析～

我们前面说过，当我们向表中插入一条记录时会有 乐观插入 和 悲观插入 的区分，但是不管怎么插入，最终导致的结果就是这条记录被放到了一个数据页中。如果希望回滚这个插入操作，那么把这条记录删除就好了，也就是说在写对应的 undo 日志时，主要是把这条记录的主键信息记上。所以设计 InnoDB 的大佬设计了一个类型为 TRX_UNDO_INSERT_REC 的 undo 日志，它的完整结构如下图所示：

根据示意图我们强调几点：

现在我们向 undo_demo 中插入两条记录：

因为记录的主键只包含一个 id 列，所以我们在对应的 undo日志 中只需要将待插入记录的 id 列占用的存储空间长度（id 列的类型为 INT，INT 类型占用的存储空间长度为 4 个字节）和真实值记录下来。本例中插入了两条记录，所以会产生两条类型为 TRX_UNDO_INSERT_REC 的 undo 日志:

我们知道插入到页面中的记录会根据记录头信息中的 next_record 属性组成一个单向链表，我们把这个链表称之为 正常记录链表；我们在前面介绍数据页结构的时候说过，被删除的记录其实也会根据记录头信息中的 next_record 属性组成一个链表，只不过这个链表中的记录占用的存储空间可以被重新利用，所以也称这个链表为 垃圾链表。Page Header 部分有一个称之为 PAGE_FREE 的属性，它指向由被删除记录组成的垃圾链表中的头节点。为了故事的顺利发展，我们先画一个图，假设此刻某个页面中的记录分布情况是这样的（这个不是 undo_demo 表中的记录，只是我们随便举的一个例子）：

为了突出主题，在这个简化版的示意图中，我们只把记录的 delete_mask 标志位展示了出来。从图中可以看出，正常记录链表 中包含了 3 条正常记录，垃圾链表 里包含了 2 条已删除记录，在 垃圾链表 中的这些记录占用的存储空间可以被重新利用。页面的 Page Header 部分的 PAGE_FREE 属性的值代表指向 垃圾链表 头节点的指针。假设现在我们准备使用 DELETE 语句把 正常记录链表 中的最后一条记录给删除掉，其实这个删除的过程需要经历两个阶段：

把 阶段二 执行完了，这条记录就算是真正的被删除掉了。这条已删除记录占用的存储空间也可以被重新利用了。画下来就是这样：

对照着图我们还要注意一点，将被删除记录加入到 垃圾链表 时，实际上加入到链表的头节点处，会跟着修改 PAGE_FREE 属性的值。

从上面的描述中我们也可以看出来，在删除语句所在的事务提交之前，只会经历 阶段一，也就是 delete mark 阶段（提交之后我们就不用回滚了，所以只需考虑对删除操作的 阶段一 做的影响进行回滚）。设计 InnoDB 的大佬为此设计了一种称之为 TRX_UNDO_DEL_MARK_REC 类型的 undo日志，它的完整结构如下图所示：

这个里边的属性也太多了点儿吧～（其实大部分属性的意思我们上面已经介绍过了） 是的，的确有点多，不过大家千万不要在意，如果记不住千万不要勉强自己，我这里把它们都列出来让大家混个脸熟而已。劳烦大家先克服一下密集恐急症，再抬头大致看一遍上面的这个类型为 TRX_UNDO_DEL_MARK_REC 的 undo 日志 中的属性，特别注意一下这几点：

该介绍的我们介绍完了，现在继续在上面那个事务 id 为 100 的事务中删除一条记录，比如我们把 id 为 1 的那条记录删除掉：

这个 delete mark 操作对应的 undo 日志 的结构就是这样：

对照着这个图，我们得注意下面几点：

在执行 UPDATE 语句时，InnoDB 对更新主键和不更新主键这两种情况有截然不同的处理方案。

因为一个事务可能包含多个语句，而且一个语句可能对若干条记录进行改动，而对每条记录进行改动前，都需要记录 1 条或 2 条的 undo日志，所以在一个事务执行过程中可能产生很多 undo日志，这些日志可能一个页面放不下，需要放到多个页面中，这些页面就通过我们上面介绍的 TRX_UNDO_PAGE_NODE 属性连成了链表：

大家往上再瞅一瞅上面的图，我们特意把链表中的第一个 Undo 页面 给标了出来，称它为 first undo page，其余的 Undo页面 称之为 normal undo page，这是因为在 first undo page 中除了记录 Undo Page Header 之外，还会记录其他的一些管理信息，这个我们稍后再说。

在一个事务执行过程中，可能混着执行 INSERT、DELETE、UPDATE 语句，也就意味着会产生不同类型的 undo日志。但是我们前面又强调过，同一个 Undo页面 要么只存储 TRX_UNDO_INSERT 大类的 undo日志，要么只存储 TRX_UNDO_UPDATE 大类的 undo日志，反正不能混着存，所以在一个事务执行过程中就可能需要 2 个 Undo页面 的链表，一个称之为 insert undo链表，另一个称之为 update undo链表，画个示意图就是这样：

另外，设计 InnoDB 的大佬规定对普通表和临时表的记录改动时产生的 undo日志 要分别记录（我们稍后阐释为什么这么做），所以在一个事务中 最多 有 4 个以 Undo页面 为节点组成的链表：

当然，并不是在事务一开始就会为这个事务分配这4个链表，具体分配策略如下：

总结一句就是： 按需分配，什么时候需要什么时候再分配，不需要就不分配。

为了尽可能提高 undo日志 的写入效率，不同事务执行过程中产生的undo日志需要被写入到不同的Undo页面链表中。比方说现在有事务 id 分别为 1、2 的两个事务，我们分别称之为 trx 1 和 trx 2，假设在这两个事务执行过程中：

InnoDB 会为 trx 1 分配 3 个链表，分别是：

InnoDB 会为 trx 2 分配 2 个链表，分别是：

综上所述，在 trx 1 和 trx 2 执行过程中，InnoDB 共需为这两个事务分配 5 个 Undo页面 链表，画个图就是这样：

如果有更多的事务，那就意味着可能会产生更多的 Undo页面 链表。

如果你有认真看过表空间那一章的话，对这个 段 的概念应该印象深刻，我们当时花了非常大的篇幅来介绍这个概念。简单讲，这个 段 是一个逻辑上的概念，本质上是由若干个零散页面和若干个完整的区组成的。比如一个 B+ 树索引被划分成两个段，一个叶子节点段，一个非叶子节点段，这样叶子节点就可以被尽可能的存到一起，非叶子节点被尽可能的存到一起。每一个段对应一个 INODE Entry 结构，这个 INODE Entry 结构描述了这个段的各种信息，比如段的 ID，段内的各种链表基节点，零散页面的页号有哪些等信息（具体该结构中每个属性的意思大家可以到表空间那一章里再次重温一下）。我们前面也说过，为了定位一个 INODE Entry，设计 InnoDB 的大佬设计了一个 Segment Header 的结构：

整个 Segment Header 占用 10 个字节大小，各个属性的意思如下：

知道了表空间ID、页号、页内偏移量，不就可以唯一定位一个 INODE Entry 的地址了么～

设计 InnoDB 的大佬规定，每一个 Undo页面 链表都对应着一个 段，称之为 Undo Log Segment。也就是说链表中的页面都是从这个段里边申请的，所以他们在 Undo页面 链表的第一个页面，也就是上面提到的 first undo page 中设计了一个称之为 Undo Log Segment Header 的部分，这个部分中包含了该链表对应的段的 segment header 信息以及其他的一些关于这个段的信息，所以 Undo 页面链表的第一个页面其实长这样：

可以看到这个 Undo 链表的第一个页面比普通页面多了个 Undo Log Segment Header，我们来看一下它的结构：

其中各个属性的意思如下：

我们上面说 Undo页面 的 Undo Page Header 部分有一个 12 字节大小的 TRX_UNDO_PAGE_NODE 属性，这个属性代表一个 List Node 结构。每一个 Undo页面 都包含 Undo Page Header 结构，这些页面就可以通过这个属性连成一个链表。这个 TRX_UNDO_PAGE_LIST 属性代表着这个链表的基节点，当然这个基节点只存在于 Undo页面 链表的第一个页面，也就是 first undo page 中。

一个事务在向 Undo页面 中写入 undo日志 时的方式是十分简单暴力的，就是直接往里怼，写完一条紧接着写另一条，各条 undo日志 之间是亲密无间的。写完一个 Undo页面 后，再从段里申请一个新页面，然后把这个页面插入到 Undo页面 链表中，继续往这个新申请的页面中写。设计 InnoDB 的大佬认为同一个事务向一个 Undo页面 链表中写入的 undo日志 算是一个组，比方说我们上面介绍的 trx 1 由于会分配 3 个 Undo页面 链表，也就会写入 3 个组的 undo日志；trx 2 由于会分配 2 个 Undo页面 链表，也就会写入 2 个组的 undo日志。在每写入一组 undo日志 时，都会在这组 undo日志 前先记录一下关于这个组的一些属性，设计 InnoDB 的大佬把存储这些属性的地方称之为 Undo Log Header。所以 Undo页面 链表的第一个页面在真正写入 undo日志 前，其实都会被填充 Undo Page Header、Undo Log Segment Header、Undo Log Header 这 3 个部分，如图所示：

这个 Undo Log Header 具体的结构如下：

哇唔，映入眼帘的又是一大坨属性，我们先大致看一下它们都是什么意思：

对于没有被重用的 Undo页面 链表来说，链表的第一个页面，也就是 first undo page 在真正写入 undo日志 前，会填充 Undo Page Header、Undo Log Segment Header、Undo Log Header 这 3 个部分，之后才开始正式写入 undo日志。对于其他的页面来说，也就是 normal undo page 在真正写入 undo日志 前，只会填充 Undo Page Header。链表的 List Base Node 存放到 first undo page 的 Undo Log Segment Header 部分，List Node 信息存放到每一个 Undo页面 的 undo Page Header 部分，所以画一个 Undo页面 链表的示意图就是这样：

我们现在知道一个事务在执行过程中最多可以分配 4 个 Undo页面 链表，在同一时刻不同事务拥有的 Undo页面 链表是不一样的，所以在同一时刻系统里其实可以有许许多多个 Undo页面 链表存在。为了更好的管理这些链表，设计 InnoDB 的大佬又设计了一个称之为 Rollback Segment Header 的页面，在这个页面中存放了各个 Undo页面 链表的 frist undo page 的 页号，他们把这些 页号 称之为 undo slot。我们可以这样理解，每个 Undo页面 链表都相当于是一个班，这个链表的 first undo page 就相当于这个班的班长，找到了这个班的班长，就可以找到班里的其他同学（其他同学相当于 normal undo page）。有时候学校需要向这些班级传达一下精神，就需要把班长都召集在会议室，这个 Rollback Segment Header 就相当于是一个会议室。

我们看一下这个称之为 Rollback Segment Header 的页面长什么样（以默认的 16KB 为例）：

设计 InnoDB 的大佬规定，每一个 Rollback Segment Header 页面都对应着一个段，这个段就称为 Rollback Segment，翻译过来就是 回滚段。与我们之前介绍的各种段不同的是，这个 Rollback Segment 里其实只有一个页面（这可能是设计 InnoDB 的大佬们的一种洁癖，他们可能觉得为了某个目的去分配页面的话都得先申请一个段，或者他们觉得虽然目前版本的 MySQL 里 Rollback Segment 里其实只有一个页面，但可能之后的版本里会增加页面也说不定）。

了解了 Rollback Segment 的含义之后，我们再来看看这个称之为 Rollback Segment Header 的页面的各个部分的含义都是什么意思：

初始情况下，由于未向任何事务分配任何 Undo页面 链表，所以对于一个 Rollback Segment Header 页面来说，它的各个 undo slot 都被设置成了一个特殊的值：FIL_NULL（对应的十六进制就是 0xFFFFFFFF），表示该 undo slot 不指向任何页面。

随着时间的流逝，开始有事务需要分配 Undo页面 链表了，就从回滚段的第一个 undo slot 开始，看看该 undo slot 的值是不是 FIL_NULL：

一个 Rollback Segment Header 页面中包含 1024 个 undo slot，如果这 1024 个 undo slot 的值都不为 FIL_NULL，这就意味着这 1024 个 undo slot 都已经名花有主（被分配给了某个事务），此时由于新事务无法再获得新的 Undo页面 链表，就会回滚这个事务并且给用户报错：

用户看到这个错误，可以选择重新执行这个事务（可能重新执行时有别的事务提交了，该事务就可以被分配 Undo页面 链表了）。

当一个事务提交时，它所占用的 undo slot 有两种命运：

我们说一个事务执行过程中最多分配 4 个 Undo页面 链表，而一个回滚段里只有 1024 个 undo slot，很显然 undo slot 的数量有点少啊。我们即使假设一个读写事务执行过程中只分配 1 个 Undo页面 链表，那 1024 个 undo slot 也只能支持 1024 个读写事务同时执行，再多了就崩溃了。这就相当于会议室只能容下 1024 个班长同时开会，如果有几千人同时到会议室开会的话，那后来的那些班长就没地方坐了，只能等待前面的人开完会自己再进去开。

话说在 InnoDB 的早期发展阶段的确只有一个回滚段，但是设计 InnoDB 的大佬后来意识到了这个问题，咋解决这问题呢？会议室不够，多盖几个会议室不就得了。所以设计 InnoDB 的大佬一口气定义了 128 个回滚段，也就相当于有了 128 × 1024 = 131072 个 undo slot。假设一个读写事务执行过程中只分配 1 个 Undo页面 链表，那么就可以同时支持 131072 个读写事务并发执行（这么多事务在一台机器上并发执行，还真没见过呢～）。

每个回滚段都对应着一个 Rollback Segment Header 页面，有 128 个回滚段，自然就要有 128 个 Rollback Segment Header 页面，这些页面的地址总得找个地方存一下吧！于是设计 InnoDB 的大佬在系统表空间的第 5 号页面的某个区域包含了 128 个 8 字节大小的格子：

每个 8 字节的格子的构造就像这样：

如果所示，每个 8 字节的格子其实由两部分组成：

所以通过上面的叙述我们可以大致清楚，在系统表空间的第5号页面中存储了 128 个 Rollback Segment Header 页面地址，每个 Rollback Segment Header 就相当于一个回滚段。在 Rollback Segment Header 页面中，又包含 1024 个 undo slot，每个 undo slot 都对应一个 Undo 页面 链表。我们画个示意图：

把图一画出来就清爽多了。

我们把这 128 个回滚段给编一下号，最开始的回滚段称之为 第0号回滚段，之后依次递增，最后一个回滚段就称之为 第127号回滚段。这 128 个回滚段可以被分成两大类：

也就是说如果一个事务在执行过程中既对普通表的记录做了改动，又对临时表的记录做了改动，那么需要为这个记录分配 2 个回滚段，再分别到这两个回滚段中分配对应的 undo slot。

不知道大家有没有疑惑，为什么要把针对普通表和临时表来划分不同种类的 回滚段 呢？这个还得从 Undo页面 本身说起，我们说 Undo页面 其实是类型为 FIL_PAGE_UNDO_LOG 的页面的简称，说到底它也是一个普通的页面。我们前面说过，在修改页面之前一定要先把对应的 redo日志 写上，这样在系统奔溃重启时才能恢复到奔溃前的状态。我们向 Undo页面 写入 undo日志 本身也是一个写页面的过程，设计 InnoDB 的大佬为此还设计了许多种 redo日志 的类型，比方说 MLOG_UNDO_HDR_CREATE、MLOG_UNDO_INSERT、MLOG_UNDO_INIT 等等等等，也就是说我们对 Undo页面 做的任何改动都会记录相应类型的 redo日志。但是对于临时表来说，因为修改临时表而产生的 undo日志 只需要在系统运行过程中有效，如果系统奔溃了，那么在重启时也不需要恢复这些 undo 日志所在的页面，所以在写针对临时表的 Undo页面 时，并不需要记录相应的 redo日志。总结一下针对普通表和临时表划分不同种类的 回滚段 的原因：在修改针对普通表的回滚段中的 Undo页面 时，需要记录对应的 redo日志，而修改针对临时表的回滚段中的 Undo页面 时，不需要记录对应的 redo日志。

上面说了一大堆的概念，大家应该有一点点的小晕，接下来我们以事务对普通表的记录做改动为例，给大家梳理一下事务执行过程中分配 Undo页面 链表时的完整过程，

对临时表的记录做改动的步骤和上述的一样，就不赘述了。不错需要再次强调一次，如果一个事务在执行过程中既对普通表的记录做了改动，又对临时表的记录做了改动，那么需要为这个记录分配 2 个回滚段。并发执行的不同事务其实也可以被分配相同的回滚段，只要分配不同的 undo slot 就可以了。

我们前面说系统中一共有 128 个回滚段，其实这只是默认值，我们可以通过启动参数 innodb_rollback_segments 来配置回滚段的数量，可配置的范围是 1~128。但是这个参数并不会影响针对临时表的回滚段数量，针对临时表的回滚段数量一直是 32，也就是说：

默认情况下，针对普通表设立的回滚段（第 0 号以及第 33~127 号回滚段）都是被分配到系统表空间的。其中的第第 0 号回滚段是一直在系统表空间的，但是第 33~127 号回滚段可以通过配置放到自定义的 undo表空间 中。但是这种配置只能在系统初始化（创建数据目录时）的时候使用，一旦初始化完成，之后就不能再次更改了。我们看一下相关启动参数：

第 33~127 号回滚段可以平均分布到不同的 undo表空间 中。

比如我们在系统初始化时指定的 innodb_rollback_segments 为 35，innodb_undo_tablespaces 为 2，这样就会将第 33、34 号回滚段分别分布到一个 undo表空间 中。

设立 undo表空间 的一个好处就是在 undo表空间 中的文件大到一定程度时，可以自动的将该 undo表空间 截断（truncate）成一个小文件。而系统表空间的大小只能不断的增大，却不能截断。