InnoDB之Undo log格式

我不是女神ヾ 2024-03-26 07:14 65阅读 0赞

### 1. 前言 ###

InnoDB有两大日志模块，分别是redo log和undo log。为了避免磁盘随机写，InnoDB设计了redo log，数据写入时只写缓冲页和redo log，脏页由后台线程异步刷盘，哪怕系统崩溃也能根据redo log恢复数据。但是我们漏了一种情况没有考虑，如果事务执行到一半系统崩溃了，redo log没刷盘还好，相当于本次事务的修改全部停留在内存里，重启后相当于什么也没做。但是，如果redo log已经刷盘了，[MySQL重启][MySQL]后依然会根据redo log恢复页面，相当于本次事务执行到一半的状态，不符合原子性。为了保证原子性，MySQL必须撤销本次事务的所有修改，让本次事务「看起来什么都没做」，这就是undo log要负责的事情。

### 2. 事务回滚 ###

事务回滚的需求是存在的，除了上述情况系统崩溃时的执行了一半的事务需要回滚，很多时候，开发者也经常需要通过命令`ROLLBACK`手动回滚事务。事务回滚后，该事务看起来什么都没做一样，它是符合[原子性][Link 1]的。

如何实现事务回滚呢？想当然，肯定要把事务中修改的数据先记下来，比如：

*  insert一条记录，就把主键记下来，回滚时删除该记录即可。
 *  delete一条记录时，把整条记录记下来，回滚时重新插入即可。
 *  update一条记录时，把对应列修改前的值全部记下来，回滚时修改回来即可。
 *  select不会修改记录，无需处理。

InnoDB其实也就是按照这个思路去设计的，每次对记录的修改，都会记一条日志，把回滚该条记录的必要数据给记录下来，这个日志就是undo log。

### 3. undo log格式 ###

undo log是针对记录的，一般每对一条记录进行一次改动，都会生成1到2条undo log。一个事务在执行过程中，可能会修改很多记录，也就会生成若干条undo log，每个事务生成的undo log都会有一个唯一编号`undo no`，从0开始依次递增，undo no越小代表日志越早生成。

另外，undo log只针对聚簇索引，只有聚簇索引记录才有`trx_id`和`roll_pointer`隐藏列，二级索引是不会生成undo log的，MySQL在事务回滚时，会自动撤销对二级索引的变更。

`roll_pointer`隐藏列占用7个字节，组成如下：

<table> 
 <thead> 
  <tr> 
   <th><strong>属性</strong></th> 
   <th><strong>长度</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>is_insert</td> 
   <td>1比特</td> 
   <td>是否是TRX_UNDO_INSERT大类</td> 
  </tr> 
  <tr> 
   <td>rseg id</td> 
   <td>7比特</td> 
   <td>回滚段id，最多128个回滚段</td> 
  </tr> 
  <tr> 
   <td>Page Number</td> 
   <td>4字节</td> 
   <td>undo log所在页号</td> 
  </tr> 
  <tr> 
   <td>Offset</td> 
   <td>2字节</td> 
   <td>undo log所在页号的偏移量</td> 
  </tr> 
 </tbody> 
</table>

和redo log一样，InnoDB也设计了很多不同类型的undo log，增删改操作对应的undo log类型都不一样。

#### 3.1 insert undo log ####

插入一条记录，对应的回滚操作就是删除该条记录，对应的undo log最需要记录的就是tableId和主键信息。InnoDB设计了`TRX_UNDO_INSERT_REC`类型的undo log来回滚insert操作。

重点关注主键信息，假设表的主键是BIGINT类型的id，我们插入了一条id=10000的记录，那么主键信息存储的内容就是`<8,10000>`，如果主键包含多列，需要把每个列的长度和值都记录下来。

#### 3.2 delete undo log ####

删除一条记录，对应的回滚操作就是把这条记录再重新插入回去，难道undo log要把一条用户记录完整的给记录下来吗？这未免也太浪费空间了，其实完全不需要这么做，这还得说回InnoDB删除记录的流程。

记录头信息里会有`next_record`属性，把记录按照主键串联成一条单向链表。页内被删除的记录也会根据该属性串联成一条单向链表，只不过这条链表的空间是可以被重用的，也称作「垃圾链表」。索引页Page Header里有`PAGE_FREE`属性，指向这条垃圾链表的头节点。记录头信息里还有`delete_mark`属性，用来标记记录是否被删除。  
![image.png][]  
当我们要删除一条记录时，实际上会有两个阶段：

*  阶段1

将记录的`delete_mark`标记为1，记录undo log，写入`trx_id`和`roll_pointer`。事务提交前，记录一直处于这种中间状态，既不是正常记录，也不是已删除记录。只有将记录从正常链表中移除，加入到垃圾链表里，记录才算真正删除，其它事务也访问不到了。  
![image.png][image.png 1]  
**为啥不直接删除记录，而是停留在中间状态？**

> 这条记录还需要为MVCC服务，其它事务可能还需要访问。

*  阶段2

事务提交后，会有专门的线程来将记录真正的删除掉，这个过程称作「**purge**」。将记录从正常链表中移除，加入到垃圾链表，InnoDB采用头插法，`PAGE_FREE`会指向该记录，记录占用的空间也可以被重用了。与此同时，InnoDB还会修改Page Header里的`PAGE_N_RECS`、`PAGE_GARBAGE`、Page Directory等信息。  
![image.png][image.png 2]  
综上所述，事务提交前，只会经历阶段1，事务提交后也就不存在回滚了。所以针对delete操作，只需要把阶段1回滚即可，又因为阶段1记录其实并没有真正删除，所以undo log其实没必要保存完整记录。InnoDB设计了`TRX_UNDO_DEL_MARK_REC`类型的undo log。

<table> 
 <thead> 
  <tr> 
   <th><strong>属性</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>end of record</td> 
   <td>本条undo log结束，下一条开始的位置</td> 
  </tr> 
  <tr> 
   <td>undo type</td> 
   <td>undo log类型</td> 
  </tr> 
  <tr> 
   <td>undo no</td> 
   <td>undo log序号</td> 
  </tr> 
  <tr> 
   <td>table id</td> 
   <td>表对应的id</td> 
  </tr> 
  <tr> 
   <td>info bits</td> 
   <td>记录头信息的前4个比特位和record_type值</td> 
  </tr> 
  <tr> 
   <td>old trx_id</td> 
   <td>旧的事务id</td> 
  </tr> 
  <tr> 
   <td>old roll_pointer</td> 
   <td>旧的回滚指针</td> 
  </tr> 
  <tr> 
   <td>主键信息</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>&lt;len,value&gt;列表</td> 
   <td>主键各列长度和值</td> 
  </tr> 
  <tr> 
   <td>index_col_info len</td> 
   <td>索引列信息总长度</td> 
  </tr> 
  <tr> 
   <td>索引各列信息</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>&lt;pos,len,value&gt;</td> 
   <td>索引各列的位置、长度和值</td> 
  </tr> 
  <tr> 
   <td>start of record</td> 
   <td>上一条undo log结束，本条开始的位置</td> 
  </tr> 
 </tbody> 
</table>

*  与insert不同的是，delete和update操作对应的undo log会记录下旧的`trx_id`和`roll_pointer`，这样就可以找到上一次对记录修改时的undo log，这些undo log串联起来就是传说中的「**版本链**」，服务于MVCC。
 *  根据主键信息定位到具体的记录，用户回滚时恢复。
 *  索引各列信息主要用于purge阶段。

#### 3.3 update undo log ####

update操作就比较复杂了，根据是否更新主键，InnoDB的处理方式也是不同的。  
**一、不更新主键**  
在不更新主键的前提下，如果更新后记录各列的长度与更新前相同，那么就可以「**就地更新**」，也就是直接在原有记录上进行更新，同时记录下undo log。

> 注意：是每个列的长度都和更新前相同，而非记录总长度和更新前相同。

就地更新的条件还是比较苛刻的，如果更新后列的长度发生变化，那么InnoDB会采用「**先删除旧记录，再插入新记录**」的方式来做更新，这里的“删除”是真的将记录删除并移入垃圾链表，而非仅仅打删除标记。  
为什么会这么做呢？

> 在索引页里记录与记录之间是紧密无间的存储在一起的，中间没有空间，如果更新后记录占用的空间变大压根就没法存储，只能删掉重新申请空间插入一条。

总之，针对这种不更新主键的情况，InnoDB设计了`TRX_UNDO_UPD_EXIST_REC`类型的undo log。

<table> 
 <thead> 
  <tr> 
   <th><strong>属性</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>end of record</td> 
   <td>本条undo log结束，下一条开始的位置</td> 
  </tr> 
  <tr> 
   <td>undo type</td> 
   <td>undo log类型</td> 
  </tr> 
  <tr> 
   <td>undo no</td> 
   <td>undo log序号</td> 
  </tr> 
  <tr> 
   <td>table id</td> 
   <td>表对应的id</td> 
  </tr> 
  <tr> 
   <td>info bits</td> 
   <td>记录头信息的前4个比特位和record_type值</td> 
  </tr> 
  <tr> 
   <td>old trx_id</td> 
   <td>旧的事务id</td> 
  </tr> 
  <tr> 
   <td>old roll_pointer</td> 
   <td>旧的回滚指针</td> 
  </tr> 
  <tr> 
   <td>主键信息</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>&lt;len,value&gt;列表</td> 
   <td>主键各列长度和值</td> 
  </tr> 
  <tr> 
   <td>n_updated</td> 
   <td>更新的列的数量</td> 
  </tr> 
  <tr> 
   <td>&lt;pod,ole_len,old_val&gt;列表</td> 
   <td>更新列的旧值</td> 
  </tr> 
  <tr> 
   <td>index_col_info len</td> 
   <td>索引列信息总长度</td> 
  </tr> 
  <tr> 
   <td>索引各列信息</td> 
   <td></td> 
  </tr> 
  <tr> 
   <td>&lt;pos,len,value&gt;</td> 
   <td>索引各列的位置、长度和值</td> 
  </tr> 
  <tr> 
   <td>start of record</td> 
   <td>上一条undo log结束，本条开始的位置</td> 
  </tr> 
 </tbody> 
</table>

**二、更新主键**  
针对update操作更新了主键的情况，InnoDB分为两个阶段来处理：

*  将旧记录进行delete mark操作，服务于MVCC。
 *  根据更新后各列的值构建一条新记录并插入。

这两个阶段，对应两条undo log，也就是上面说的`TRX_UNDO_DEL_MARK_REC`和`TRX_UNDO_INSERT_REC`。

### 4. 对覆盖索引查询的影响 ###

聚簇索引记录会有`trx_id`和`roll_pointer`隐藏列，通过undo log里的`roll_pointer`串联形成版本链，即一条记录存在多个版本，在select时会判断哪些版本对当前事务可见。  
但是undo log只针对聚簇索引，二级索引没有`roll_pointer`，也不会生成undo log。我们又知道，InnoDB有个查询优化叫「**覆盖索引查询**」，即直接扫描二级索引返回结果，不再根据主键回表查询，可以大大提高数据查询的效率。

这时就存在一个问题，**覆盖索引查询时，无法判断二级索引记录是否对当前事务可见！**  
InnoDB的解决方案是，在Page Header里有一个属性叫`PAGE_MAX_TRX_ID`，它代表修改当前页的最大事务id，如果`PAGE_MAX_TRX_ID`小于当前活跃的最小事务id，代表修改当前页的事务都提交了，可以直接使用覆盖索引查询，无需回表。反之，就需要回表根据聚簇索引的`trx_id`和`roll_pointer`以及对应的undo log来判断哪些二级索引记录是对当前事务可见的。

[MySQL]: https://so.csdn.net/so/search?q=MySQL%E9%87%8D%E5%90%AF&spm=1001.2101.3001.7020
[Link 1]: https://so.csdn.net/so/search?q=%E5%8E%9F%E5%AD%90%E6%80%A7&spm=1001.2101.3001.7020
[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/88a0f36caefe4ed59cad5b698bdb5041.png
[image.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/af49315c938e4d98ba101630595a93e3.png
[image.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/b2ea1ae4529b4268b864e6947b9f864b.png