undo日志详解-编程知识

一、undo日志介绍

上一节详细的说了redo日志，redo日志的功能就是把增删改操作都记录着，如果断电导致内存中的脏页丢失，可以根据磁盘中的redo日志文件进行恢复。redo日志被设计出来是为了保证数据库的持久性，undo日志设计出来是为了保证数据库的原子性。一个事务开启之后，做增删改操作，会记录redo日志，但是如果后悔了进行回滚，redo日志是做不到回退的，这时候就需要undo日志了。

总结：记住一句话，redo日志保证了数据库的持久性，undo日志保证了数据库的原子性。

二、undo日志格式

一般每次对记录做一次改动就会对应生成一条undo日志。有些更新语句记录的操作中，也可能会生成两条undo日志。

一个事务在执行过程中可能新增，删除，更新若干条记录，同样也会生成若干条记录，这些undo日志会从0开始编号，并且是按照顺序生成，被称为第0号undo日志，1号。。。

这些undo日志是被记录到类型为FIL_PAGE_UNDO_LOG页面。这些页面可以从系统表空间（ibdata1文件）中分配，也可以从一种专门存放undo日志的表空间，也就是undo tablespace。

insert操作对应的undo日志

前面文章说过，插入操作分为乐观插入和悲观插入。但是关于插入操作无非就是把记录放到数据页中，如果想要回滚就直接把这条记录删除就可以，也就是说在写对应的undo日志时，主要是把这条记录的主键记录，这样删除记录就可以根据主键找到二级索引和聚簇索引上的记录。InnoDB设计了一个类型为为TRX_UNDO_INSERT_REC的undo⽇志

属性说明：

undo no上面说过，从0开始，只要这个事务没提交，按顺序生成undo日志，依次递增。

主键的每个列占用的存储空间和真实值。为什么存储主键就可以了，上面也说了，如果想要回滚就直接把这条记录删除就可以，也就是说在写对应的undo日志时，主要是把这条记录的主键记录，这样删除记录就可以根据主键找到二级索引和聚簇索引上的记录。后面的delete和update也一样不再强调。

向 undo_demo 中插⼊两条记录：

BEGIN; # 显式开启⼀个事务，假设该事务的 id 为 100

# 插⼊两条记录

INSERT INTO undo_demo(id, key1, col)

VALUES (1, 'AWM' , ' 狙击枪 ' ), (2, 'M416' , ' 步枪 ' );

因为主键只包含id，所以插入的两条记录，会按照顺序生成两个undo日志，第一个undo日志：

第二个undo日志：

roll_pointer隐藏列的含义

前面的文章介绍过记录的三个隐藏列，只剩roll_pointer没有说过，他本质上就是一个指向记录对应的undo日志的一个指针，比方说上面的插入两条记录的操作，每条记录都有对应的一个undo日志。关系就是记录被存储到类型为FIL_PAGE_INDEX的页面（前面说的数据页），undo日志被放到类型为FIL_PAGE_UNDO_LOG的页面中

delete操作对应的undo日志

前面的文章详细的说过数据页中的记录会组成一个单向链表，我们把这个链表称之为正常记录链表。并且删除某条记录，被删除的记录也会形成一个链表，叫垃圾链表，并且这条垃圾链表中记录占用的存储空间可以被重新利用。

上图简化了记录，只标记了delete_mask属性，我们删除最后一条记录，删除的过程需要经历两个阶段：

阶段一：只是将该记录的delete_mask表示为设置为1，修改记录隐藏列trx_id、roll_pointer这些隐藏列的值。

在事务提交之前，删除的记录都处于这个中间状态，被删除的记录没有被加入垃圾链表（为了实现MVCC功能）。

阶段二：当删除的语句所在事务提交之后，会有专门的线程把记录加入垃圾链表中，并且调整页面的其他信息。这个阶段称为purge。

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

从上图我们可以看到真正删除之后被删除的记录加入垃圾链表的头结点，修改垃圾链表PAGE_FREE属性的值。

⻚⾯的Page Header部分有⼀个PAGE_GARBAGE属性，该属性记录着当前⻚⾯中可重⽤存储空间占⽤的总字节数。每当有已删除记录被加⼊到垃圾链表后，都会把这个PAGE_GARBAGE属性的值加上该已删除记录占⽤的存储空间⼤⼩。PAGE_FREE指向垃圾链表的头节点，之后每当新插⼊记录时，⾸先判断PAGE_FREE指向的头节点代表的已删除记录占⽤的存储空间是否⾜够容纳这条新插⼊的记录，如果不可以容纳，就直接向⻚⾯中申请新的空间来存储这条记录（是的，你没看错，并不会尝试遍历整个垃圾链表，找到⼀个可以容纳新记录的节点）。如果可以容纳，那么直接重⽤这条已删除记录的存储空间，并且把PAGE_FREE指向垃圾链表中的下⼀条已删除记录。但是

这⾥有⼀个问题，如果新插⼊的那条记录占⽤的存储空间⼤⼩⼩于垃圾链表的头节点占⽤的存储空间⼤⼩，那就意味头节点对应的记录占⽤的存储空间⾥有⼀部分空间⽤不到，这部分空间就被称之为碎⽚空间。那这些碎⽚空间岂不是永远都⽤不到了么？其实也不是，这些碎⽚空间占⽤的存储空间⼤⼩会被统计到PAGE_GARBAGE属性中，这些碎⽚空间在整个⻚⾯快使⽤完前并不会被重新利⽤，不过当⻚⾯快满时，如果再插⼊⼀条记录，此时⻚⾯中并不能分配⼀条完整记录的空间，这时候会⾸先看⼀看PAGE_GARBAGE的空间和剩余可利⽤的空间加起来是不是可以容纳下这条记录，如果可以的话，InnoDB会尝试重新组织⻚内的记录，重新组织的过程就是先开辟⼀个临时⻚⾯，把⻚⾯内的记录依次插⼊⼀遍，因为依次插⼊时并不会产⽣碎⽚，之后再把临时⻚⾯的内容复制到本⻚⾯，这样就可以把那些碎⽚空间都解放出来（很显然重新组织⻚⾯内的记录⽐较耗费性能）。

不知道大家意识到没有，在删除语句所在的事务提交之前，只会经历阶段一，也就是delete mark阶段，提交之后我们就不用回滚，所以只需要考虑删除操作阶段一做的影响进行回滚。InnoDB为阶段一设计了 TRX_UNDO_DEL_MARK_REC 类型的 undo ⽇志

undo日志使用的ibp，到底有没有undo buffer？

undo日志写在磁盘的系统表空间，即数据目录的ibdata1文件中，是字扩展文件

undo日志刷入磁盘的时机，在redo日志之后，因为undo日志也是写在了页上面当然不是数据页，而是其他类型的页，所以在写页之前肯定会先刷入redo日志。

undo页其实在事务提交之后就没用了，就可以删除了。

参考：

https://blog.51cto.com/u_16099245/8284858?u_atoken=cb0a23c68bb36e0b51bdd6698c0d1b1e&u_asession=010oqemvtD-SI70HvdIIJ3SD6rL-0g4lqUd_UCHB5kIzJd_RzP7PK5M9OMtfYEHkSMdlmHJsN3PcAI060GRB4YZGyPlBJUEqctiaTooWaXr7I&u_asig=05KSFHoAoEbI0nFMyiGbILePlRrb4fDSnENTW1oe0zxFMc_aeYEexCgEgeGZ16H7ZE1DUDCzmL2emmn6qmFC9CC_XK8dYD1h4eorn2e4KHNprayj0S6sDcNlfu97C_4rOSwYUPHbo6E_XIjuXpGnuIY3njx0LLgd3IEivFU82Koe5g2QMxYs6lyXb1lFWKql56bKAECQJI7JT5rwB3i3DMxmVX6G2FWvrtzLd69hasdI_jtcevR-HxX_TJmPgBpiSXfv5D2tGhDz888pbf-PhVCPH6b79Mch4xN3KRAVxzONmsTpJ-4hEVCCqo-GZeD3WUZHi7af-9T9DT_5BT1SiXZw&u_aref=KA7pqKy7uBwsbhILbK67J7v6BqM%3D

MySQL 的undo什么时候写到硬盘？ - 知乎

003_Mysql之事务详解redo log、undolog 和 MVCC_undolog存放在磁盘的哪里-CSDN博客