Redo log 重做日志
-
redo log 是为了确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log 进行重做，进而达到事务的持久性这一特性
-
redo log 物理格式的日志，记录的是物理数据页面的修改信息，其redo log 是顺序写入redo log file 的物理文件中去。
-
redo log 流转过程
-
先将原始数据从磁盘中进行读取，修改数据的内存拷贝。
-
生成一条日志信息写入到 redo log buffer(
大小固定,通过循环写的方式进行写入)，记录物理数据被修改的值. -
当事务提交的时候，将redo log buffer 的数据通过
fsync操作持久化刷新到redo log file 中， 并且对 redo log file 采用追加写的方式 -
定期将内存中修改的数据刷新进入磁盘之中
-
当 redo log 写满文件的时候，回到开头重新循环写。如下图所示, write pos 是当前记录的位置，一边写一边后移，写到第3号文件末尾就要回到第0号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。
Undo log 日志 -
保存了事务执行之前的版本，可以用于回滚，同时可以提供多版本并发控制下的读(MVCC), 也就是非锁定读
-
逻辑格式的日志，将数据从逻辑上恢复到事务之前的状态，而不是从物理页面上进行操作。
-
innodb 存储引擎中, undo log 分为
insert undo log和update undo log -
insert undo log是指在insert 操作中产生的undo log，因为insert操作的记录，只对事务本身可见，对其他事务不可见。故该undo log可以在事务提交后直接删除，不需要进行purge操作。
-
而update undo log记录的是对delete 和update操作产生的undo log，该undo log可能需要提供MVCC机制，因此不能再事务提交时就进行删除。提交时放入undo log链表，等待purge线程进行最后的删除。
-
补充：purge线程两个主要作用是：清理undo页和清除page里面带有Delete_Bit标识的数据行。在InnoDB中，事务中的Delete操作实际上并不是真正的删除掉数据行，而是一种Delete Mark操作，在记录上标识Delete_Bit，而不删除记录。是一种"假删除",只是做了个标记，真正的删除工作需要后台purge线程去完成。