MySQL 中 redo log、undo log、binlog 的总结

本文主要总结下重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）的概念。redo log 是物理日志，undo log 和 binlog 是逻辑日志，物理日志的恢复速度远快于逻辑日志。

1、redo log、undo log

innodb 事务日志包括 redo log 和 undo log，redo log 是重做日志，提供前滚操作，undo log 是回滚日志，提供回滚操作，其中前者保证事务的持久性，后者保证事务的原子性，两者可以统称为事务日志。

前滚和回滚的区别

redo log

• 生命周期

事务开始之后，就开始产生 redo log 日志了，在事务执行的过程中，redo log 开始逐步落盘，当对应事务的脏页写入到磁盘之后，redo log 的使命就完成了，它所占用的空间也就可以被覆盖了。

• 存储内容

redo log 包括两部分：一是内存中的日志缓冲(redo log buffer)，该部分日志是易失性的；二是磁盘上的重做日志文件(redo log file)，该部分日志是持久的，redo log 存储的是物理格式的日志，记录的是物理数据页面的修改信息，它是顺序写入 redo log file 中的。

• 落盘方式（将 innodb 日志缓冲区的日志刷新到磁盘）

1，Master Thread 每秒一次执行刷新 Innodb_log_buffer 到重做日志文件
　　2，每个事务提交时会将重做日志刷新到重做日志文件
　　3，当重做日志缓存可用空间少于一半时，重做日志缓存被刷新到重做日志文件

undo log

• 生命周期

事务开始之前，将当前事务版本生成 undo log，undo log 也会产生 redo log 来保证 undo log 的可靠性。当事务提交之后，undo log 并不能立马被删除，而是放入待清理的链表，由 purge 线程判断是否有其它事务在使用 undo 段中表的上一个事务之前的版本信息，从而决定是否可以清理 undo log 的日志空间。

• 存储内容

undo log 存储的是逻辑格式的日志，保存了事务发生之前的上一个版本的数据，可以用于回滚。当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着 undo 链找到满足其可见性的记录。

• 存储位置

默认情况下，undo 文件是保存在共享表空间的，也即 ibdatafile 文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的 undo log 信息，这些信息全部保存在共享表空间中，因此共享表空间可能会变得很大，默认情况下，也就是 undo log 使用共享表空间的时候，被“撑大”的共享表空间是不会、也不能自动收缩的。因此，MySQL5.7 之后的“独立 undo 表空间”的配置就显得很有必要了。

2、binlog

binlog 用于主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。用于数据库的基于时间点、位点等的还原操作。binlog 的模式分三种：Statement、Row、Mixed。

binlog 的三种模式

• 生命周期

事务提交的时候，一次性将事务中的 sql 语句（一个事务可能对应多个 sql 语句）按照一定的格式记录到 binlog 中，这里与 redo log 很明显的差异就是 redo log 并不一定是在事务提交的时候才刷新到磁盘，而是在事务开始之后就开始逐步写入磁盘。binlog 的默认保存时间是由参数 expire_logs_days 配置的，对于非活动的日志文件，在生成时间超过 expire_logs_days 配置的天数之后，会被自动删除。

总之，redo log 和 undo log 是保证本地事务的，binlog 是用于主从复制的。