MySQL-redo log 和 undo log(简单易懂)

一、redo log

假设我们在bufferpool中修改了页，然后在事务提交后，发生了故障导致内存中的修改数据全都没了，这种时候我们应该怎么处理。

①修改了一条我们就往磁盘中更新一条，但这样会对性能性能造成影响，因为I/O次数太多了。

②我们只需要在我们修改的时候，记录一下修改内容就好了，而这就是redo log

二、undo log

事务是具有原子性的，在我们提交事务的时候，事务内的操作要么全部提交，要么全部撤销。

我们在将数据恢复成原来的样子，就是回滚。而数据库为了回滚而记录的日志，就是撤销日志（undo log）。

分配事务id的时机

当事务对表中记录进行修改时，都会生成一个事务id

分配事务id的规则：

系统会在内部维护一个全局变量，当我们需要分配事务id时，都会把这个全局变量赋值给事务id，并且自增1.每当这个全局变量变成256的倍数时，我们就会赋值给一个MAX TRX ID的属性，当下一次启动的时候，系统就会把这个属性加上256赋值给上面的全局变量。

在page页中的头信息中trx_id就是事务id。

我们以delete操作为例进行讲解：

当我们在进行删除的时候，会根据记录的next_record指针生成一个全新的链表，但是这个链表所占用的空间可以被重新利用，所以被称为垃圾链表，page_free指向垃圾链表的头节点，当我们删除一条记录时，他都会插入到垃圾链表的头节点。

当我们在删除一条记录时，首先会将记录头信息中的delete_flag变为1，而next_record指针不会立即断开，此时若是回滚数据，只是将delete_flag变回0即可。当next_record断开后，这条记录会被放入垃圾链表的头节点处，并且page hander中的page_free的指针会指向此节点。

删除记录信息的roll_pointer会指向上一条的undolog，而插入会指向本身记录的undolog。