mysqlmy.cnf路径_MySQL 中的重做日志，回滚日志以及二进制日志的简单总结

MySQL中有六种类型的日志文件：重做日志、回滚日志、二进制日志、错误日志、慢查询日志、通用查询日志和中继日志。

其中重做日志和回滚日志与事务操作密切相关，二进制日志也与事务操作有一定的关系，这三个日志对于理解MySQL中的事务操作有着重要的意义。

这里简单总结一下和这三者有一定关系的日志。

重做日志

影响：

保证事务的持久性。为了避免故障时脏页被写入磁盘，在MySQL服务重启时根据重做日志重新进行事务处理，从而实现事务的持久性。

内容：

物理格式日志记录了物理数据页的修改信息，其重做日志按顺序写入重做日志文件物理文件。

何时生成：

重做日志在事务开始后生成，重做日志不是在事务提交时写入磁盘，而是在事务执行过程中写入重做日志文件。

发布时：

当相应事务的脏页被写入磁盘后，重做日志的使命就完成了，重做日志所占用的空间可以被重新使用（覆盖）。

对应的物理文件：

默认情况下，相应的物理文件位于数据库的数据目录中。

e_dir指定日志文件组所在的路径，默认值为./，即数据库的数据目录中。

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

文件的大小和数量由以下两个参数配置：

重做日志文件的大小。

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

其他：

知道重做日志何时写入磁盘非常重要。如前所述，它是在事务开始后逐渐写入磁盘的。

之所以重做日志在事务开始后才逐渐写入重做日志文件，而事务提交后不一定写入重做日志缓存，是因为重做日志有一个默认大小为8M（这里设置了16M）的缓存区域，存储引擎在写入重做日志时会优先考虑。

然后日志缓冲区会通过以下三种方式刷新到磁盘：

每秒刷新一次重做日志文件。

每个事务提交并将重做日志刷新到重做日志文件。

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

由此我们可以看出，重做日志写入磁盘不止一种方式，特别是第一种方式，写入重做日志文件是线程的计划任务。

因此重做日志写入磁盘并不一定在事务提交时就完成，而是随着事务开始逐渐开始。

另外，原文来自《MySQL技术内幕存储引擎》（）：

即使事务尚未提交，存储引擎仍然会每秒将重做日志缓冲区刷新到重做日志文件。

了解这一点很重要，因为它可以很好地解释为什么即使是最大的事务的 () 时间也很短。

撤消日志

影响：

保存了事务发生前的一个版本的数据，可以用于回滚，并能提供多版本并发控制（MVCC）下的读取，也就是非锁定读取

内容：

逻辑日志在进行undo操作时，只是将数据恢复到事务发生之前的状态，而不是对物理页进行操作，这一点与redo日志不同。

何时生成：

事务开始前，会将当前版本生成到undo log中，undo还会生成redo，保证undo log的可靠性。

发布时：

事务提交后，undo log并不会立刻被删除，而是被放入一个链表中等待清理。purge线程会判断undo段中是否有其他事务正在使用表中前一个事务之前的版本信息，从而决定是否可以清理undo log的日志空间。

对应的物理文件：

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

.6、undo表空间可以配置为独立文件，但需要提前在配置文件中配置，数据库初始化后生效，undo日志文件数量不可更改。

如果初始化数据库前没有做相关配置，则不能配置为独立表空间。

.7以后独立undo表空间的配置参数如下：

y = /data// – 撤消独立表空间的存储目录

= 128 – 回滚段为 128KB

ces = 4 – 指定有 4 个撤消日志文件

如果undo使用的共享表空间，这个共享表空间不仅仅存储了undo信息，共享表空间默认为MySQL数据目录，其属性通过参数h配置。

其他：

Undo 是事务开始前保存的修改数据的一个版本，当产生undo log的时候，也会产生一种类似于保护事务持久性的机制。

默认情况下undo文件保存在共享表空间中，也就是文件中，当数据库发生一些大的事务操作时，会产生大量的undo信息，并且全部保存在共享表空间中。

因此共享表空间可能会变得很大，默认情况下，当undo log使用共享表空间时，“扩大”的共享表空间不会也不能自动收缩。

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

二进制日志()：

影响：

用于复制。主从复制中，从数据库会重放主数据库上的数据，实现主从同步。

用于数据库的时间点还原。

内容：

逻辑格式的日志可以简单地视为执行事务中的 SQL 语句。

但它又不只是一条SQL语句那么简单，它包含了执行过的SQL语句的逆向信息（增删改查），也就是说它对应着自己和它的逆向；它对应着执行前后版本的信息；它对应着信息本身。

经过分析，一些真相就会被揭露。

因此我们可以基于 实现类似的闪回功能，其实就是依赖 中的日志记录。

何时生成：

在事务提交的时候，会一次性按照一定的格式记录该事务内的所有SQL语句（一个事务可能对应多条SQL语句）。

这里明显的区别是，重做日志不一定在事务提交时就刷新到磁盘，而是在事务开始后逐渐写入磁盘。

所以对于事务的提交，即使是较大的事务，()也是很快的，但如果开启的话，较大事务的提交可能会变慢。

这是因为它在事务提交时被写入一次，可以通过测试来验证。

发布时：

默认是按照参数配置的保留时间，也就是说，对于不活动的日志文件，在生成时间超过配置的天数后将被自动删除。

对应的物理文件：

配置文件的路径为，日志文件指定大小，当日志文件达到指定的最大大小时，进行滚动更新，生成新的日志文件。

每个日志文件都由统一的索引文件组织。

其他：

二进制日志的作用之一是恢复数据库，它和重做日志很相似，很多人把它们混淆了，但两者有着本质的区别。

功能不同：redo log用于保证事务的持久性，是事务级别的。作为恢复功能，是数据库级别的（当然也可以精确到事务级别）。虽然两者都有恢复的意思，但是对数据的保护程度是不一样的。

不同内容：redo log是物理日志，是数据页修改的物理记录；是逻辑日志，可以简单的认为是记录SQL语句。

另外日志产生的时间，可以释放的时间，以及释放时的清理机制也是完全不同的。

基于物理日志的重做日志高于基于语句逻辑日志的重做日志时数据恢复的效率更高。

关于redo log的写入顺序以及事务何时提交，在主从复制的时候（当然也包括使用基于时间的恢复），为了保证主从一致性，必须严格一致。MySQL通过两阶段提交的过程来完成事务的一致性，也就是redo log的一致性。理论上是先写redo log，再写两条日志，只有两条日志都成功提交（刷到磁盘）时，事务才真正完成。

参考：

总结：

在MySQL中，上述三种日志的每一种类型都可以详细到写一章，这里就粗略的概括一下这三种日志的一些特点和作用，以帮助理解MySQL中的东西以及事物背后的原理。