MySQL中有六种日志文件，分别是：重做日志(redo log)、回滚日志(undo log)、二进制日志(binlog)、错误日志(errorlog)、慢查询日志(slow query log)、一般查询日志(general log)，中继日志(relay log)。

其中重做日志和回滚日志与事务操作息息相关，二进制日志也与事务操作有必定的关系日志分类学生，这三种日志，对理解MySQL中的事务操作有着重要的意义。

这里简单小结一下这两者具有必定相关性的日志。

一、重做日志(redo log)

1、作用

确保事务的持久性。

防止在出现故障的时间点，尚有脏页未读入磁盘，在重启mysql服务的之后，根据redo log进行重做，从而超过事务的持久性这一特点。

2、内容

物理格式的日志，记录的是物理数据页面的更改的信息，其redo log是排序写入redo log file的物理文件中去的。

3、什么时候产生

事务开始以后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始读取redo log文件中。

4、什么时候释放

当对应事务的脏页写入到磁盘然后，redo log的使命也就完成了，重做日志占用的空间就可以重用(被覆盖)。

5、对应的物理文件

默认状况下，对应的物理文件位于的data目录下的ib_logfile1&ib_logfile2

innodb_log_group_home_dir 指定日志文件组所在的模式，默认./ ，表示在的数据目录下。

innodb_log_files_in_group 指定重做日志文件组中文件的数量，默认2

关于文件的大小和次数，由一下两个参数配置

innodb_log_file_size 重做日志文件的大小。

innodb_mirrored_log_groups 指定了日志镜像文件组的数量，默认1

6、其他

很重要一点，redo log是哪个之后写盘的？前面说了是在事物开始以后逐渐写盘的。

之所以说重做日志是在事务开始以后逐渐写入重做日志文件，而不一定是事务提交才读取重做日志缓存，

原因就是，重做日志有一个缓存区Innodb_log_buffer，Innodb_log_buffer的默认大小为8M(这里设置的16M),Innodb存储引擎先将重做日志写入innodb_log_buffer中。

然后会借助以上三种方法将innodb日志缓冲区的日志刷新到磁盘

1，Master Thread 每秒一次执行刷新Innodb_log_buffer到重做日志文件。

2，每个事务提交时会将重做日志刷新到重做日志文件。

3，当重做日志缓存可用空间 少于一半时，重做日志缓存被刷新到重做日志文件

由此可以看出，重做日志通过不止一种方式读取到磁盘，尤其是针对第一种方式，Innodb_log_buffer到重做日志文件是Master Thread线程的定时任务。

因此重做日志的写盘，并不必定是随着事务的递交才读取重做日志文件的，而是随着事务的起初，逐步开始的。

另外引用《MySQL技术内幕 Innodb 存储引擎》(page37)上的原话：

即使某个事务还没有提交，Innodb存储引擎依然每秒会将重做日志缓存刷新到重做日志文件。

这一点是需要要知道的，因为这可以较好地解释再大的事务的提交(commit)的时间也有很短暂的。

二、回滚日志(undo log)

1、作用

保存了事务出现之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读(MVCC)，也即非锁定读

2、内容

逻辑格式的日志，在执行undo的之后，仅仅是将数据从逻辑上恢复至事务之前的状况，而不是从物理页面上操作推动的，这一点是不同于redo log的。

3、什么时候产生

事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来确保undo log的可靠性

4、什么时候释放

当事务提交以后，undo log并不能立马被删除，

而是放在待清理的数组，由purge线程判断能否由其它事务在使用undo段中表的上一个事务之前的版本信息，决定能否可以清理undo log的日志空间。

5、对应的物理文件

MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。

MySQL5.6以后，undo表空间可以配置成独立的文件，但是提前必须在配置文件中配置，完成初始化后生效且不可改变undo log文件的个数

如果初始化之前没有进行相关配置，那么就能够配置成独立的表空间了。

关于MySQL5.7之后的独立undo 表空间配置参数如下

innodb_undo_directory = /data/undospace/ –undo独立表空间的存放目录

innodb_undo_logs = 128 –回滚段为128KB

innodb_undo_tablespaces = 4 –指定有4个undo log文件

如果undo使用的共享表空间，这个共享表空间中又不仅仅是内存了undo的信息，共享表空间的默认为与MySQL的数据目录以下，其属性由参数innodb_data_file_path配置。

6、其他

undo是在事务开始之前保存的被设置数据的一个版本，产生undo日志的之后，同样会伴随类似于保护事务持久化机制的redolog的产生。

默认状况下undo文件是维持在共享表空间的，也即ibdatafile文件中，当中出现一些大的事务性操作的之后，要生成少量的undo信息，全部储存在共享表空间中的。

因此共享表空间可能会变的很大，默认状况下，也就是undo 日志使用共享表空间的之后，被“撑大”的共享表空间是不会也不能自动收缩的。

因此，mysql5.7之后的“独立undo 表空间”的配置就变得很有必要了。

三、二进制日志(binlog)

1、作用

用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步；

用于的基于时间点的还原；

2、内容

逻辑格式的日志，可以简洁认为就是执行过的事务中的sql语句。

但又不完全是sql语句那么简洁，而是包含了执行的sql子句(增删改)反向的信息，

也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。

在使用mysqlbinlog解析binlog之后一些就会真相大白。

因此可以基于binlog做到类似于oracle的闪回功能，其实都是依赖于binlog中的日志记录。

3、什么时候产生

事务提交的之后，一次性将事务中的sql子句(一个事物也许对应多个sql子句)按照一定的格式记录到binlog中。

这里与redo log很明显的差别就是redo log并不必定是在事务提交的之后刷新到磁盘，redo log是在事务开始以后就起初逐步写入磁盘。

因此针对事务的提交，即便是较大的事务，提交(commit)都是很快的，但是在进入了bin_log的状况下，对于较大事务的提交，可能会变得非常慢一些。

这是因为binlog是在事务提交的之后一次性写入的导致的，这些可以借助测试验证。

4、什么时候释放

binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数以后，会被自动删除。

5、对应的物理文件

配置文件的模式为log_bin_basename，binlog日志文件根据选定大小，当日志文件超过指定的最大的大小然后，进行滚动升级，生成新的日志文件。

对于每个binlog日志文件日志分类学生，通过一个统一的index文件来组织。

6、其他

二进制日志的作用之一是还原的，这与redo log很类似，很混淆过，但是它们有本质的不同：

关于事务提交时，redo log和binlog的读取顺序，为了确保主从复制之后的主从一致(当然也包含使用binlog进行基于时间点还原的状况)，是要严格一致的，

MySQL通过两阶段提交过程来完成事务的一致性的，也即redo log和binlog的一致性的，理论上是先写redo log，再写binlog，两个日志都提交失败(刷入磁盘)，事务才算真正的完成。

四、总结

MySQL中，对于以下三种日志，每一种细化出来都可以够写一个章节的，这里简要地总结了一下三种日志的一些缺点和作用，以帮助理解MySQL中的事物或者事物背后的原理。

原文：

本文来自电脑杂谈，转载请注明本文网址：

http://www.pc-fly.com/a/jisuanjixue/article-121726-1.html