MySQL中的undo log简述

骑猪看日落 2022-12-26 10:26 85阅读 0赞

上一篇讲完了[redo log][]，这篇博客再来讲讲undo log，重做日志

undo log的作用是事务回滚或者事务提交失败时用来恢复数据的，还有一个作用是用在了MVCC机制中（这个我们后面再讲），undo log跟redo log这种物理日志不同，它是一个逻辑日志

当我们执行了增删改操作之后，undo log其实就代表了一个回滚的操作，如果是insert操作，那么重做之后就会delete这些数据；如果是delete操作的话，那么会insert这些数据；如果是update操作的话，那么就是反向的update操作（undo log的产生同时也会产生redo log日志）

undo log并不是一次性的，InnoDB存储引擎中undo log是可以复用的，当提交事务时，如果undo页的使用空间小于3/4的话，那就就会被复用，新的undo log会被加入到当前undo log的后面。一个事务提交之后，undo log可能还会记录其他事务需要的记录，所以undo log和undo log所在的页如果要删除的话，得由一个叫做purge的线程来控制

在InnoDB引擎中，undo log分为了两种，一种是insert undo log，另一种是update undo log，接下来分别来介绍一下

*  insert undo log：顾名思义，这是用在insert语句上的undo log，因为事务具有隔离性，所以一个事务的insert语句对于其他事务是不可见的，所以只要事务提交了，那么这个undo log就没用了，就会被删除，这里是不需要purge来进行操作的

一个insert undo log中记录了undo的开始位置、下一个undo log的位置、undo log类型、事务ID、对应的表对象和所有主键的列和值，这样的话，如果执行undo log进行重做，就可以直接删除这些新增的数据了

*  update redo log：这种类型对应了update和delete两种操作产生的undo log，这种undo log我们之前提到了，不能够在事务结束之后就立马删除，最后需要由purge线程来删除

update undo log中记录的信息比insert undo log要更多，因为这里的操作不仅对应了update，还有delete；同时每个修改的列信息都需要记录在undo log中，对于不同的undo log类型，可能还需要记录对索引列所做的修改，这里就不再具体展开了

实际上delete操作，并不是真的删除数据，而是记录一个删除标记，最终删除还是由purge线程来完成

update操作的话，需要分成两种情况，一种是更新主键值，还有一种是更新非主键值  
如果是更新非主键值，undo log直接记录反向的update操作即可；如果是更新主键值的话，那么就会先将原主键记录标记为已删除，再插入一条新的目标行

最后再来稍微解释一下什么时候pruge线程才能真正执行undo log的删除，之所以不能在事务提交之后立马进行undo log的处理，就是因为MVCC机制，可能还有其他的事务正在引用这些undo log，这时只是将记录的delete flag记为1，也就是标记删除的意思。只有最后没有任何事务引用这行记录的时候，purge线程才会真正执行删除的操作，清理之前的记录版本

[redo log]: https://blog.csdn.net/LO_YUN/article/details/110238316