MySQL中有六种日志文件，分别是：重做日志（redo log）、回滚日志（undo log）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slow query log）、一般查询日志（general log），中继日志（relay log）。
其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有一定的关系，这三种日志，对理解MySQL中的事务操作有着重要的意义。
这里简单总结一下这三者具有一定相关性的日志。
重做日志（redo log）
- 作用：
防止在发生故障的时间点，尚有脏页
未写入磁盘（事务提交之后，数据写入磁盘之前宕机），在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。 - 内容：
物理格式的日志，记录的是物理数据页面的修改信息，其redo log是顺序写入redo log file的物理文件中去的。 - 生成时机：
事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。 - 释放时机：
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。
缓冲区 Innodb_log_buffer
重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为16Mb，Innodb 存储引擎先将重做日志写入 Innodb_log_buffer中，然后会通过以下三种方式将 Innodb 日志缓冲区的日志刷新到磁盘：
- Master Thread 每秒一次执行刷新 Innodb_log_buffer 到重做日志文件
- 每个事务提交时会刷新。
- 当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件。
因此重做日志的写盘，并不一定是随着事务的提交才写入重做日志文件的，而是随着事务的开始，逐步开始的。
回滚日志（undo log）
- 作用：
保存了事务发生之前数据的一个版本，可以用于回滚。事务回滚时，会根据 undo log 将数据从逻辑上恢复至事务之前的状态。 - 内容：
逻辑格式的日志，在执行undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。 - 生成时机：
事务开始之前，将当前事务版本生成 undo log，undo 也会产生 redo 来保证 undo log 的可靠性。每一次写操作都会生成 undo log，比如 update 操作，会生成一条更新前的记录信息，比如主键ID，需要更新的字段以及字段对应的旧值。对于 DELETE 操作，在 delete mark 操作时，会获取该条记录最近一次的 undo log 记录，生成的新的 undo log 记录了旧记录的 trx_id（事务编号） 和 old roll_pointer（上一个 undo log 的位置） ，这样回滚时，就可以直接找到删除之前的 undo log 进行回滚操作。 - 释放时机：
当事务提交之后，undo log并不能立马被删除，而是放入待清理的链表，由 purge 线程判断是否有其他事务在使用 undo 段中表的上一个事务之前的版本信息，决定是否可以清理 undo log 的日志空间。
二进制日志（binlog）
- 作用：
- 用于复制，在主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。
- 用于数据库的基于时间点的还原。
- 内容：
逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。 - 生成时机：
事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
这里与redo log很明显的差异就是redo log并不一定是在事务提交的时候才刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。 - 释放时机：
binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。
MySQL通过两阶段提交过程来完成事务的一致性的，也即 redo log 和 binlog 的一致性的，理论上是先写 redo log，再写 binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。
