意思-一文带你了解MySQL之undo日志

我们在前边学习事务的时候说过事务需要保证，也就是。但是有的时候事务会出现一些情况，比如：

事务执行过程中可能遇到各种错误，比如服务器本身的错误，操作系统错误，甚至是突然断电导致的错误情况二：程序员可以在事务执行过程中手动输入语句结束当前的事务的执行

以上这两种情况都会导致事务执行到一半就结束，但是事务执行过程中可能已经修改了很多东西，为了保证事务的，我们需要把东西改回原先的样子，这个过程就称之为（英文名：），这样就可以造成一个假象：这个事务看起来什么都没做，所以符合原子性要求。

好比小时候我们和小伙伴们完纸牌。悔牌就是一种非常典型的回滚操作，比如你出两张三纸牌，悔牌对应的操作就是把两张三纸牌在拿出去。数据库中的回滚跟悔牌差不多，你插入了一条记录，回滚操作对应的就是把这条记录删除掉；你更新了一条记录，回滚操作对应的就是把该记录更新为旧值；你删除了一条记录，回滚操作对应的自然就是把该记录再插进去。说的貌似很简单的样子

从上边的描述中我们已经能隐约感觉到，每当我们要对一条记录做改动时（这里的改动可以指、、），都需要留一手 —— 把回滚时所需的东西都给记下来。比如说：

你插入一条记录时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的记录删掉就好了你删除了一条记录，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了你修改了一条记录，至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值就好了

数据库这些为了回滚?记录的这些东东称之为撤销日志，英文名为，我们称之为。这里需要注意的一点是，由于查询操作（SELECT）并不会修改任何?户记录，所以在查询操作执行时，并不需要记录相应的日志。在真实的中，日志其实并不像我们上边所说的那么简单，不同类型的操作产?的日志的格式也是不同的，不过先暂时把这些容易让人脑子糊的具体细节放一放，我们先回过头来看看事务id是什么东西

我们前边在学习事务简介时说过，一个事务可以是一个，或者是一个：

我们可以通过语句开启一个，在只读事务中不可以对普通的表（其他事务也能访问到的表）进行增、删、改操作，但可以对临时表做增、删、改操作我们可以通过语句开启一个，或者使用、语句开启的事务默认也算是，在读写事务中可以对表执行增删改查操作。

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

对于来说，只有在它第一次对某个用户创建的临时表执行增、删、改操作时才会为这个事务分配一个事务id，否则的话是不分配事务id的

我们前边说过对某个查询语句执行分析它的查询计划时，有时候在Extra列会看到Using temporary的提示，这个表明在执行该查询语句时会用到内部临时表。这个所谓的内部临时表和我们手动用创建的用户临时表并不一样，在事务回滚时并不需要把执行SELECT语句过程中用到的内部临时表也回滚，在执行SELECT语句用到内部临时表时并不会为它分配事务id。

对于来说，只有在它第一次对某个表（包括用户创建的临时表）执行增、删、改操作时才会为这个事务分配一个事务id，否则的话也是不分配事务id的

有的时候虽然我们开启了一个，但是在这个事务中全是查询语句，并没有执行增、删、改的语句，那也就意味着这个事务并不会被分配一个事务id

说了半天，事务id有啥子用？这个先保密哈，后边会一步步的详细唠叨。现在只要知道只有在事务对表中的记录做改动时才会为这个事务分配一个唯一的事务id。

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

服务器会在内存中维护一个全局变量，每当需要为某个事务分配一个时，就会把该变量的值当作事务id分配给该事务，并且把该变量自增1每当这个变量的值为的倍数时，就会将该变量的值刷新到系统表空间的?号为5的??中一个称之为的属性处，这个属性的存储空间当系统下一次重新启动时，会将上边提到的属性加载到内存中，将该值加上256之后赋值给我们前边提到的全局变量（因为在上次关机时该全局变

量的值可能大于属性值）

这样就可以保证整个系统中分配的事务id值是一个递增的数字。先被分配id的事务得到的是较小的事务id，后被分配id的事务得到的是较大的事务id。

我们前边学习记录行格式的时候重点强调过：聚簇索引的记录除了会保存完整的用户数据以外，而且还会自动添加名为、的隐藏列，如果用户，还会自动添加一个名为的隐藏列。所以一条记录在页面中的真实结构看起来就是这样的：

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

为了实现事务的原子性，存储引擎在实际进行、、一条记录时，都需要先把对应的日志记下来。一般每对一条记录做一次改动，就对应着一条日志，但在某些更新记录的操作中，也可能会对应着2条日志，这个我们后边会仔细唠叨。一个事务在执行过程中可能、、若干条记录，也就是说需要记录很多条对应的日志，这些日志会被从开始编号，也就是说根据生成的顺序分别被称为第0号undo日志、第1号undo日志、…、第n号undo日志等，这个编号也被称之为。

这些undo日志是被记录到类型为（对应的十六进制是，忘记了页面类型是个啥的同学需要回过头再看看前边的章节）的页面中。这些页面可以从系统表空间中分配，也可以从一种专门存放undo日志的表空间，也就是所谓的中分配。不过关于如何分配存储日志的页面这个事情我们稍后再说，现在先来看看不同操作都会产生什么样子的日志吧～ 为了故事的顺利发展，我们先来创建一个名为的表：

这个表中有3个列，其中列是主键，我们为列建立了一个，col列是一个普通的列。我们前边介绍的数据字典时说过，每个表都会被分配一个唯一的，我们可以通过系统数据库中的表来查看某个表对应的是什么，现在我们查看一下对应的是多少：

从查询结果可以看出，表对应的为，先把这个值记住，我们后边有用

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

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

在一个事务中是的，也就是说只要事务没提交，每生成一条undo日志，那么该条日志的undo no就增1。

如果记录中的主键只包含一个列，那么在类型为的日志中只需要把该列占用的和记录下来，如果记录中的主键包含，那么占用的都需要记录下来（图中的就代表列占用的存储空间大小，就代表列的真实值）。

当我们向某个表中插入一条记录时，实际上需要向聚簇索引和所有的二级索引都插入一条记录。不过记录undo日志时，我们只需要考虑向聚簇索引插入记录时的情况就好了，因为其实聚簇索引记录和二级索引记录是一一对应的，我们在回滚插入操作时，只需要知道这条记

录的主键信息，然后根据主键信息做对应的删除操作，做删除操作时就会顺带着把所有二级索引中相应的记录也删除掉。后边说到的DELETE操作和UPDATE操作对应的undo日志也都是针对聚簇索引记录而?的，我们之后就不强调了。

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

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

第一条日志的为，记录主键占用的存储空间长度为，真实值为。画一个示意图就是这样：

第二条日志的为，记录主键占用的存储空间长度为，真实值为。画一个示意图就是这样：

与第一条对比，和有不同。

roll_pointer隐藏列的含义

是时候揭开的真实面纱了，这个占用个字节的字段其实一点都不神秘，本质上就是一个指向记录对应的。比如说我们上边向表里插入了条记录，每条记录都有与其对应的一条。记录被存储到了类型为的页面中（就是我们前边一直所说的数据页），日志被存放到了类型为的页面中。效果如图所示：

从图中也可以更直观的看出来，本质就是一个指针，指向记录对应的日志。不过这7个字节的的每一个字节具体的含义我们后边唠叨完如何分配存储日志的页面之后再具体说哈～

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

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

阶段一：仅仅将记录的标识位设置为，其他的不做修改（其实会修改记录的、这些隐藏列的值）。InnoDB把这个阶段称之为k。把这个过程画下来就是这样：

可以看到，正常记录链表中的最后一条记录的，但是并没有被加入到。也就是此时记录处于一个，在删除语句所在的事务提交之前，被删除的记录一直都处于这种所谓的。

为啥会有这种奇怪的中间状态呢？其实主要是为了实现一个称之为MVCC的功能，哈哈，稍后再介绍。

阶段二：，会有后来真正的把记录删除掉。所谓真正的删除就是把该记录从中移除，并且加入到中，然后还要调整一些页面的其他信息，比如页面中的用户记录数量、上次插入记录的位置、垃圾链表头节点的指针、页面中可重用的字节数量、还有页?录的一些信息等等。InnoDB的把这个阶段称之为。

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

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

页面的Page Header部分有一个PAGE_GARBAGE属性，该属性记录着当前页面中可重用存储空间占用的总字节数。每当有已删除记录被加入到垃圾链表后，都会把这个PAGE_GARBAGE属性的值加上该已删除记录占用的存储空间大小。PAGE_FREE指向垃圾链表的头节点，之后每当新插入记录时，?先判断PAGE_FREE指向的头节点代表的已删除记录占用的存储空间是否足够容纳这条新插入的记录，如果不可以容纳，就直接向页面中申请新的空间来存储这条记录（是的，你没看错，并不会尝试遍历整个垃圾链表，找到一个可以容纳新记录的节点）。如果可以容纳，那么直接重用这条已删除记录的存储空间，并且把PAGE_FREE指向垃圾链表中的下一条已删除记录。但是这里有一个问题，如果新插入的那条记录占用的存储空间大小小于垃圾链表的头节点占用的存储空间大小，那就意味头节点对应的记录占用的存储空间里有一部分空间用不到，这部分空间就被称之为碎片空间。那这些碎片空间岂不是永远都用不到了么？其实也不是，这些碎片空间占用的存储空间大小会被统计到PAGE_GARBAGE属性中，这些碎片空间在整个页面快使用完前并不会被重新利用，不过当页面快满时，如果再插入一条记录，此时页面中并不能分配一条完整记录的空间，这时候会?先看一看PAGE_GARBAGE的空间和剩余可利用的空间加起来是不是可以容纳下这条记录，如果可以的话，InnoDB会尝试重新组织页内的记录，重新组织的过程就是先开辟一个临时页面，把页面内的记录依次插入一遍，因为依次插入时并不会产生碎片，之后再把临时页面的内容复制到本页面，这样就可以把那些碎片空间都解放出来（很显然重新组织页面内的记录比较耗费性能）。

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

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

在对一条记录进行操作前，需要把该记录的旧的和隐藏列的值都给记到对应的日志中来，就是我们图中显示的和属性。这样有一个好处，那就是可以通过日志的找到记录在修改之前对应的日志。比如说在一个事务中，我们先插入了一条记录，然后又执行对该记录的删除操作，这个过程的示意图就是这样：

从图中可以看出来，执行完操作后，它对应的日志和操作对应的日志就串成了一个链表。这个很有意思啊，这个链表就称之为，现在貌似看不出这个版本链有啥用，等我们再往后看看，讲完操作对应的日志后，这个所谓的版本链就慢慢的展现出它的?逼之处了。

与类型为的日志不同，类型为的日志还多了一个的内容，也就是说如果某个列被包含在某个索引中，那么它的相关信息就应该被记录到这个部分，所谓的相关信息包括该列在记录中的位置（用表示），该列占用的存储空间大小（用表示），该列实际值（用表示）。所以存储的内容实质上就是的一个列表。这部分信息主要是用在事务提交后，对该做真正删除的阶段二，也就是阶段中使用的，具体如何使用现在我们可以忽略～

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

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

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

因为这条undo日志是id为100的事务中产生的。

在对记录做操作时，记录的隐藏列的值是（也就是说对该记录最近的一次修改就发生在本事务中），所以把填入属性中。然后把记录的隐藏列的值取出来，填入属性中，这样就可以通过属性值找到最近一次对该记录做改动时产生的日志。

由于demo18表中有2个索引：，一个是。只要是包含在索引中的列，那么这个列在记录中的位置（），占用存储空间大小（）和实际值（）就需要存储到undo日志中。

对于主键来说，只包含一个列，存储到undo日志中的相关信息分别是：

：列是主键，也就是在记录的，它对应的pos值为0。pos占用1个字节来存储。

：id列的类型为INT，占用4个字节，所以len的值为4。len占用1个字节来存储。

：在被删除的记录中id列的值为1，也就是value的值为1。value占用4个字节来存储。

画一个图演示一下就是这样：

所以对于列来说，最终存储的结果就是<>，存储这些信息占用的存储空间大小为。

对于来说，只包含一个列，存储到日志中的相关信息分别是：

：key1列是排在id列、trx_id列、roll_pointer列之后的，它对应的pos值为。pos占用1个字节来存储。

：key1列的类型为VARCHAR(100)，使用utf8字符集，被删除的记录实际存储的内容是AWM，所以一共占用3个字节，也就是所以len的值为3。len占用1个字节来存储。

：在被删除的记录中key1列的值为AWM，也就是value的值为AWM。value占用3个字节来存储。

画一个图演示一下就是这样：

所以对于列来说，最终存储的结果就是<>，存储这些信息占用的存储空间大小为个字节。

从上边的叙述中可以看到，和共占用个字节。然后本身占用个字节，所以加起来一共占用个字节，把数字13就填到了的属性中。

在执行语句时，InnoDB对和这两种情况有截然不同的处理如案。

在不更新主键的情况下，又可以细分为被更新的列占用的存储空间不发生变化和发生变化的情况。

就地更新（in-place update）

更新记录时，对于被更新的每个列来说，如果更新后的列和更新前的列占用的存储空间都一样大，那么就可以进行就地更新，也就是直接在原记录的基础上修改对应列的值。再次强调一边，是每个列在更新前后占用的存储空间一样大，有任何一个被更新的列更新前比更新后占用的存储空间大，或者更新前比更新后占用的存储空间小都不能进行就地更新。比如说现在demo18表里还有一条id值为2的记录，它的各个列占用的大小如图所示（因为采用utf8字符集，所以’步枪’这两个字符占用6个字节）：

假如我们有这样的语句：

在这个UPDATE语句中，col列从步枪被更新为手枪，前后都占用6个字节，也就是占用的存储空间大小未改变；key1列从M416被更新为P92，也就是从4个字

节被更新为3个字节，这就不满足就地更新需要的条件了，所以不能进行就地更新。但是如果UPDATE语句长这样：

由于各个被更新的列在更新前后占用的存储空间是一样大的，所以这样的语句可以执行就地更新。

先删除掉旧记录，再插入新记录

在不更新主键的情况下，如果有任何一个被更新的列更新前和更新后占用的存储空间大小不一致，那么就需要先把这条旧的记录从聚簇索引页面中删除掉，然后再根据更新后列的值创建一条新的记录插入到页面中。

请注意一下，我们这里所说的删除并不是操作，而是真正的删除掉，也就是把这条记录从正常记录链表中移除并加入到垃圾链表中，并且修改页面中相应的统计信息（比如、等这些信息）。不过这里做真正删除操作的线程并不是在唠叨语句中做操作时使用的另外专门的线程，而是由用户线程同步执行真正的删除操作，真正删除之后紧接着就要根据各个列更新后的值创建的新记录插入。

这里如果新创建的记录占用的存储空间大小不超过旧记录占用的空间，那么可以直接重用被加入到垃圾链表中的旧记录所占用的存储空间，否则的话需要在页面中新申请一段空间以供新记录使用，如果本页面内已经没有可用的空间的话，那就需要进行页面分裂操作，然后再插入新记录。

针对UPDATE不更新主键的情况（包括上边所说的就地更新和先删除旧记录再插入新记录），InnoDB设计了一种类型为的undo日志，它的完整结构如下：

其实大部分属性和我们介绍过的类型的undo日志是类似的，不过还是要注意这么几点：

属性表示本条UPDATE语句执行后将有几个列被更新，后边跟着的分别表示被更新列在记录中的位置、更新前该列占用的存储空间大小、更新前该列的真实值。如果在语句中更新的列包含索引列，那么也会添加索引列各列信息这个部分，否则的话是不会添加这个部分的。

现在继续在上边那个事务为的事务中更新一条记录，比如我们把为的那条记录更新一下：

这个语句更新的列大小都没有改动，所以可以的如式来执行，在真正改动页面记录时，会先记录一条类型为的undo日志，长这样：

对照着这个图我们注意一下这几个地如：

因为这条日志是为的事务中产生的第条日志，所以它对应的就是。这条日志的指向为1的那条日志，也就是插入主键值为的记录时产生的那条日志，也就是最近一次对该记录做改动时产生的日志。由于本条语句中更新了索引列的值，所以需要记录一下索引列各列信息部分，也就是把主键和列更新前的信息填入。

在聚簇索引中，记录是按照主键值的大小连成了一个单向链表的，如果我们更新了某条记录的主键值，意味着这条记录在聚簇索引中的位置将会发生改变，比如你将记录的，如果还有非常多的记录的主键值分布在1 ~ 10000之间的话，那么这两条记录在聚簇索引中就有可能离得非常远，甚至中间隔了好多个页面。针对语句中更新了记录主键值的这种情况，在聚簇索引中分了两步处理：

将旧记录进行delete mark操作

这里是delete mark操作！也就是说在语句所在的事务提交前，对旧记录只做一个操作，在事务提交后才由专门的线程做操作，把它加入到垃圾链表中。这里一定要和我们上边所说的在不更新记录主键值时，先真正删除旧记录，再插入新记录的如式区分开！

之所以只对旧记录做delete mark操作，是因为别的事务同时也可能访问这条记录，如果把它真正的删除加入到垃圾链表后，别的事务就访问不到了。这个功能就是所谓的MVCC，我们后边的章节中会详细唠叨什么是个MVCC。

根据更新后各列的值创建一条新记录，并将其插入到聚簇索引中（需重新定位插入的位置）。

由于更新后的记录主键值发生了改变，所以需要重新从聚簇索引中定位这条记录所在的位置，然后把它插进去。

针对语句更新记录主键值的这种情况，在对该记录进行操作前，会记录一条类型为的undo日志；之后插入新记录时，会记录一条类型为的日志，也就是说每对一条记录的主键值做改动时，会记录2条undo日志。这些日志的格式我们上边都唠叨过了，就不赘述了。

在的过程中会使用到多个链表，很多链表都有同样的节点结构，如图所示：

在某个表空间内，我们可以通过一个页的页号和在页内的偏移量来唯一定位一个节点的位置，这两个信息也就相当于指向这个节点的一个指针。所以：

和的组合就是指向前一个节点的指针和的组合就是指向后一个节点的指针。

整个占用12个字节的存储空间。为了更好的管理链表，InnoDB的提出了一个，里边存储了这个、以及，基节点的结构示意图如下：

其中：

表明该链表一共有多少节点。的组合就是指向链表头节点的指针。的组合就是指向链表尾节点的指针。

整个占用个字节的存储空间。所以使用和这两个结构组成的链表的示意图就是这样：

我们前边唠叨表空间的时候说过，表空间其实是由许许多多的的，页面。这些页面有不同的类型，比如类型为的页面用于存储聚簇索引以及二级索引，类型为的页面用于存储表空间头部信息的，还有其他各种类型的页面，其中有一种称之为类型的页面是专门用来的，这种类型的页面的通用结构如下图所示（以默认的16KB大小为例）：

类型为的页我们就简称为页面。上图中的和是各种页面都有的通用结构，我们前边已经学习了很多遍了，这里就不赘述了。是所特有的，我们来看一下它的结构：

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

：本页面准备存储什么种类的undo日志。

我们前边介绍了好几种类型的undo日志，它们可以被分为两个大类：

（使用十进制1表示）：类型为的undo日志属于此大类，一般由语句产生，或者在语句中有更新主键的情况也会产生此类型的日志。

（使用十进制2表示），除了类型为的日志，其他类型的日志都属于这个大类，比如我们前边说的、等，一般由、语句产生的日志属于这个大类。

这个属性可选的值就是上边的两个，用来标记本页面用于存储哪个大类的日志，不同大类的日志不能混着存储，比如一个页面的属性值为，那么这个页面就只能存储类型为的日志，其他类型的undo日志就不能放到这个页面中了。

之所以把undo日志分成两个大类，是因为类型为TRX_UNDO_INSERT_REC的undo日志在事务提交后可以直接删除掉，而其他类型的undo日志还需要为所谓的MVCC服务，不能直接删除掉，对它们的处理需要区别对待。当然，如果你看这段话迷迷糊糊的话，那就不需要再看一遍了，现在只需要知道undo日志分为2个大类就好了，更详细的东西我们后边会有讲解。

：表示在当前页面中是从什么位置开始存储日志的，或者说表示第一条日志在本页面中的起始偏移量。

：与上边的对应，表示当前页面中存储的最后一条日志结束时的偏移量，或者说从这个位置开始，可以继续写入新的undo日志。

假设现在向页面中写入了3条undo日志，那么和的示意图就是这样：

当然，在最初一条undo日志也没写入的情况下，和的值是相同的。

TRX_UNDO_PAGE_NODE：代表一个List Node结构（链表的普通节点，我们上边刚说的），下边马上用到这个属性，稍安勿躁。

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

大家可以看一看上边的图，一边情况下把链表中的第一个Undo页称它为，因为在中除了记录之外，还会记录其他的一些管理信息。其余的Undo页面称之为。

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

另外，对普通表和临时表的记录改动时产生的日志要分别记录（后边会有讲解），所以在一个事务中最多有4个以页面为节点组成的链表：

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

刚刚开启事务时，一个Undo页面链表也不分配。当事务执行过程中向普通表中插入记录或者执行更新记录主键- - 的操作之后，就会为其分配一个普通表的链表。当事务执行过程中删除或者更新了普通表中的记录之后，就会为其分配一个普通表的链表。当事务执行过程中向临时表中插入记录或者执行更新记录主键的操作之后，就会为其分配一个临时表的链表。当事务执行过程中删除或者更新了临时表中的记录之后，就会为其分配一个临时表的链表。

总结一下就是：。

为了尽可能提高undo日志的写入效率，。比如说现在有事务id分别为1、2的两个事务，我们分别称之为和，假设在这两个事务执行过程中：

对普通表做了操作，对临时表做了和操作。

会为分配个链表，分别是：

针对普通表的链表针对临时表的链表针对临时表的链表。 trx 2对普通表做了INSERT、UPDATE和DELETE操作，没有对临时表做改动。

会为分配个链表，分别是：

针对普通表的insert undo链表针对普通表的update undo链表。

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

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

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

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

Space ID of the INODE Entry：INODE Entry结构所在的表空间ID。

Page Number of the INODE Entry：INODE Entry结构所在的页面页号。

Byte Offset of the INODE Ent：INODE Entry结构在该页面中的偏移量

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

这部分关于段的各种概念我们在表空间那一章中都有详细解释，在这里重提一下只是为了唤醒大家沉睡的记忆，如果有任何不清楚的地方可以再次跳回表空间的那一章仔细读一下

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

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

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

：本Undo页面链表处在什么状态。一个可能处在的状态包括如下：

：活跃状态，也就是一个活跃的事务正在往这个段里边写入undo日志。

：被缓存的状态。处在该状态的Undo页面链表等待着之后被其他事务重用。

：对于insert undo链表来说，如果在它对应的事务提交之后，该链表不能被重用，那么就会处于这种状态。

：对于update undo链表来说，如果在它对应的事务提交之后，该链表不能被重用，那么就会处于这种状态。

：包含处于PREPARE阶段的事务产生的undo日志

Undo页面链表什么时候会被重用，怎么重用我们之后会详细说的。事务的PREPARE阶段是在所谓的分布式事务中才出现的，本书中不会介绍更多关于分布式事务的事情，所以大家目前忽略这个状态就好了

：本Undo页面链表中最后一个的位置。

：本页面链表对应的段的信息（就是我们上一节介绍的那个10字节结构，通过这个信息可以找到该段对应的）

：Undo页面链表的基节点。

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

Undo Log Header

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

这个具体的结构如下：

又是一大堆属性，我们先大致看一下它们都是啥意思：

：生成本组undo日志的事务id

：事务提交后生成的一个需要序号，使用此序号来标记事务的提交顺序（先提交的此序号小，后提交的此序号大）。

：标记本组日志中是否包含由于操作产生的undo日志。

：表示本组undo日志中第一条undo日志的在页面中的偏移量。

：本组undo日志是否包含XID信息。

：标记本组undo日志是不是由DDL语句产生的。

：如果TRX_UNDO_DICT_TRANS为真，那么本属性表示DDL语句操作的表的table id。

：下一组的undo日志在页面中开始的偏移量。

：上一组的undo日志在页面中开始的偏移量。

一般来说一个Undo页面链表只存储一个事务执行过程中产生的一组undo日志，但是在某些情况下，可能会在一个事务提交之后，之后开启的事务重复利用这个Undo页面链表，这样就会导致一个Undo页面中可能存放多组Undo日志，TRX_UNDO_NEXT_LOG和TRX_UNDO_PREV_LOG就是用来标记下一组和上一组undo日志在页面中的偏移量的。关于什么时候重用Undo页面链表，怎么重用这个链表我们稍后会详细说明的，现在先理解TRX_UNDO_NEXT_LOG和TRX_UNDO_PREV_LOG这两个属性的意思就好了。

：一个12字节的List Node结构，代表一个称之为History链表的节点。

小结

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

我们前边说为了能提高并发执行的多个事务写入日志的性能，决定为每个事务单独分配相应的页面链表（最多可能单独分配4个链表）。但是这样也造成了一些问题，比如其实大部分事务执行过程中可能只修改了一条或几条记录，针对某个Undo页面链表只产生了非常少的undo日志，这些undo日志可能只占用一丢丢存储空间，每开启一个事务就新创建一个页面链表（虽然这个链表中只有一个页面）来存储这么一丢丢undo日志岂不是太浪费了么？的确是挺浪费，于是InnoDB决定在事务提交后在某些情况下重用该事务的页面链表。一个页面链表是否可以被重用的条件很简单：

该链表中只包含一个页面

如果一个事务执行过程中产生了，那么它可能申请非常多的页面加入到Undo页面链表中。在该事物提交后，如果将整个链表中的页面都重用，那就意味着即使新的事务并没有向该页面链表中写入很多日志，那该链表中也得维护非常多的页面，那些用不到的页面也不能被别的事务所使用，这样就造成了另一种浪费。所以的规定，只有在Undo页面链表中只包含一个页面时，该链表才可以被下一个事务所重用

该Undo页面已经使用的空间

我们前边说过，Undo页面链表按照存储的undo日志所属的大类可以被分为链表和链表两种，这两种链表在被重用时的策略也是不同的，我们分别看一下

insert undo链表

链表中只存储类型为的日志，这种类型的undo日志在事务提交之后就没用了，就可以被清除掉。所以在某个事务提交后，重用这个事务的insert undo链表（这个链表中只有一个页面）时，可以直接把之前事务写入的一组undo日志覆盖掉，从头开始写入新事务的一组undo日志，如下图所示：

如图所示，假设有一个事务使用的链表，到事务提交时，只向insert undo链表中插入了3条undo日志，这个insert undo链表只申请了一个Undo页面。假设此刻，那么下一个事务就可以重用这个链表（链表中只有一个页面）。假设此时有一个新事务重用了该链表，那么可以直接把旧的一组undo日志覆盖掉，写入一组新的日志。

update undo链表

在一个事务提交后，它的链表中的日志也不能立即删除掉（这些日志用于MVCC，我们后边会说的）。所以如果之后的事务想重用链表时，就不能覆盖之前事务写入的日志。这样就相当于在同一个页面中写入了多组的日志，效果看起来就是这样

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

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

规定，每一个页面都对应着一个段，这个段就称为，也就是。与我们之前介绍的各种段不同的是，这个里其实只有一个页面（这可能是可能觉得为了某个目的去分配页面的话都得先申请一个段，或者他们觉得虽然目前版本的里里其实只有一个页面，但可能之后的版本里会增加页面也说不定）。

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

：本中管理的所有页面链表中的页面数量之和的最大值。换句话说，本。

该属性的值默认为无限大，也就是我们想写多少Undo页面都可以。

无限大其实也只是个夸张的说法，4个字节能表示最大的数也就是0xFFFFFFFF，但是我们之后会看到，0xFFFFFFFF这个数有特殊用途，所以实际上TRX_RSEG_MAX_SIZE的值为0xFFFFFFFE。

：链表占用的页面数量。

：链表的基节点。

：本对应的10字节大小的结构，通过它可以找到本段对应的。

：各个页面链表的的页号集合，也就是集合。

一个页号占用个字节，对于大小的页面来说，这个部分共存储了个，所以共需1

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

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

如果是，那么在表空间中新创建一个段（也就是），然后从段里申请一个页面作为页面链表的，然后把该的值设置为刚刚申请的这个页面的页号，这样也就意味着这个被分配给了这个事务。

如果不是，说明该已经指向了一个链表，也就是说这个已经被别的事务占用了，那就跳到下一个，判断该的值是不是，重复上边的步骤。

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

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

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

如果该指向的页面链表符合被重用的条件（就是我们上边说的Undo页面链表只占用一个页面并且已使用空间小于整个页面的3/4）。

该就处于被缓存的状态，规定这时该页面链表的属性（该属性在的r部分）会被设置为。

被缓存的都会被加入到一个链表，根据对应的页面链表的类型不同，也会被加入到不同的链表：

如果对应的页面链表是链表，则该会被加入链表。

如果对应的页面链表是链表，则该会被加入链表。

一个回滚段就对应着上述两个链表，如果有新事务要分配时，先从对应的链表中找。如果没有被缓存的，才会到回滚段页面中再去找。

如果该指向的页面链表不符合被重用的条件，那么针对该对应的页面链表类型不同，也会有不同的处理：

如果对应的页面链表是链表，则该页面链表的属性会被设置为，之后该页面链表对应的段会被释放掉（也就意味着段中的页面可以被挪作他用），然后把该的值设置为。

如果对应的页面链表是链表，则该页面链表的属性会被设置为，则会将该的值设置为，然后将本次事务写入的一组日志放到所谓的链表中（需要注意的是，这里并不会将Undo页面链表对应的段给释放掉，因为这些日志还有用呢～）

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

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

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

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

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

4字节大小的，代表一个表空间的ID。

4字节大小的，代表一个页号。

也就是说每个8字节大小的相当于一个指针，指向某个表空间中的某个页面，这些页面就是。这里需要注意的一点事，要定位一个Rollback Segment Header还需要知道对应的表空间ID，这也就意味着不同的回滚段可能分布在不同的表空间中。

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

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

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

。其中第0号回滚段必须在系统表空间中（就是说第0号回滚段对应的Rollback Segment Header页面必须在系统表空间中），第33～127号回滚段既可以在系统表空间中，也可以在自己配置的undo表空间中，关于怎么配置我们稍后再说。

如果一个事务在执行过程中由于对普通表的记录做了改动需要分配Undo页面链表时，必须从这一类的段中分配相应的undo slot。

。这些回滚段必须在临时表空间（对应着数据目录中的ibtmp1文件）中。

如果一个事务在执行过程中由于对临时表的记录做了改动需要分配Undo页面链表时，必须从这一类的段中分配相应的。

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

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

如果我们仅仅对普通表的记录做了改动，那么只会为该事务分配针对普通表的回滚段，不分配针对临时表的回滚段。但是如果我们仅仅对临时表的记录做了改动，那么既会为该事务分配针对普通表的回滚段，又会为其分配针对临时表的回滚段（不过分配了回滚段并不会立即分配undo slot，只有在真正需要Undo页面链表时才会去分配回滚段中的undo slot）。

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

事务在执行过程中对普通表的记录首次做改动之前，首先会到系统表空间的第5号页面中分配一个回滚段（其实就是获取一个页面的地址）。一旦某个回滚段被分配给了这个事务，那么之后该事务中再对普通表的记录做改动时，就不会重复分配了。

使用传说中的（循环使用）方式来分配回滚段。比如当前事务分配了第0号回滚段，那么下一个事务就要分配第33号回滚段，下下个事务就要分配第34号回滚段，简单一点的说就是这些回滚段被轮着分配给不同的事务（就是这么简单粗暴，没啥好说的）。

在分配到回滚段后，首先看一下这个回滚段的两个链表有没有已经缓存了的，比如如果事务做的是操作，就去回滚段对应的i链表中看看有没有缓存的；如果事务做的是操作，就去回滚段对应的链表中看看有没有缓存的。如果有缓存的，那么就把这个缓存的分配给该事务。

如果没有缓存的可供分配，那么就要到页面中找一个可用的分配给当前事务。

从页面中分配可用的的方式我们上边也说过了，就是从第0个开始，如果该的值为，意味着这个是空闲的，就把这个分配给当前事务，否则查看第1个是否满足条件，依次类推，直到最后一个。如果这1024个undo slot都没有值为的情况，就直接报错喽（一般不会出现这种情况）～

找到可用的后，如果该是从链表中获取的，那么它对应的已经分配了，否则的话需要重新分配一个，然后从该中申请一个页面作为页面链表的。

然后事务就可以把日志写入到上边申请的！

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

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

如果我们把的值设置为，那么只会有个针对普通表的可用回滚段，但是仍然有个针对临时表的可用回滚段。

如果我们把的值设置为之间的数，效果和将其设置为是一样的。

如果我们把设置为的数，那么针对普通表的可用回滚段数量就是。

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

通过指定表空间所在的目录，如果没有指定该参数，则默认表空间所在的目录就是数据目录。

通过定义表空间的数量。该参数的默认值为，表明不创建任何表空间。

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

如果我们在系统初始化的时候指定了创建了undo表空间，那么系统表空间中的第0号回滚段将处于不可用状态。

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

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