这是我参与「第三届青训营 -后端场」笔记创作活动的的第10篇笔记
Undolog（回滚日志/重做日志）
Undo Log 是为了实现事务的原子性，事务中执行失败，进行回滚，在MySQL数据库 InnoDB 存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。由引擎层的InnoDB引擎实现,是逻辑日志,记录数据修改被修改前的值。
原理:
Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到Undo Log。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。
回滚时机?
- 用户调用 rollback 主动回滚
- 事务出错
- 辅助 redo log 实现事务持久性
undo log 的清除
当事务提交的时候，innodb不会立即删除undo log，因为后续还可能会用到undo log，如隔离级别为repeatable read时，事务读取的都是开启事务时的最新提交行版本，只要该事务不结束，该行版本就不能删除，即undo log不能删除。
但是在事务提交的时候，会将该事务对应的undo log放入到删除列表中，未来通过purge来删除。并且提交事务时，还会判断undo log分配的页是否可以重用，如果可以重用，则会分配给后面来的事务，避免为每个独立的事务分配独立的undo log页而浪费存储空间和性能。
undo log 主要分为两种：
- insert undo log
代表事务在 insert 新记录时产生的
undo log, 只在事务回滚时需要，并且在事务提交后可以被立即丢弃。 - update undo log
事务在进行 update 或 delete 时产生的
undo log; 不仅在事务回滚时需要，在快照读时也需要；所以不能随便删除，只有在快速读或事务回滚不涉及该日志时，对应的日志才会被 purge 线程统一清除
purge
从前面的分析可以看出，为了实现 InnoDB 的 MVCC 机制，更新或者删除操作都只是设置一下老记录的 deleted_bit ，并不真正将过时的记录删除。
为了节省磁盘空间，InnoDB 有专门的 purge 线程来清理 deleted_bit 为 true 的记录。为了不影响 MVCC 的正常工作，purge 线程自己也维护了一个read view（这个 read view 相当于系统中最老活跃事务的 read view ）;如果某个记录的 deleted_bit 为 true ，并且 DB_TRX_ID 相对于 purge 线程的 read view 可见，那么这条记录一定是可以被安全清除的。
undo log+redo log保证持久性
除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化,如数据库异常之后的恢复机制。
因为未提交的事务和回滚了的事务也会记录在Redo Log，因此在进行恢复时,这些事务要进行特殊的的处理。有2种不同的恢复策略：
A. 进行恢复时，只重做已经提交了的事务。 B. 进行恢复时，重做所有事务包括未提交的事务和回滚了的事务。然后通过Undo Log回滚那些未提交的事务。
MySQL数据库InnoDB存储引擎使用了B策略,InnoDB存储引擎中的恢复机制有几个特点：
-
Undo Log回滚那些未提交的事务，被回滚了的事务在恢复时先
redo再undo，也不会破坏数据的一致性 -
必须要在写
Redo Log之前将对应的Undo Log写入磁盘。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以象数据一样缓存起来，而不用在redo log之前写入磁盘了。
