MySQL有六种日志文件，分别是：重做日志（redolog）、回滚日志（undolog）、二进制日志（binlog）、错误日志（errorlog）、慢查询日志（slowquerylog）、通用查询log（通用日志），relaylog（中继日志）。其中，重做日志和回滚日志与事务操作密切相关，二进制日志也与事务操作相关。这三个日志对于理解MySQL中的事务操作具有重要意义。这里简单总结一下三个相关的日志。一、重做日志（redolog）1.保证事务持久性的功能。为了防止故障时脏页被写入磁盘，当mysql服务重启时，会根据redolog重做，从而达到事务持久化的特性。2、内容物理格式的日志记录物理数据页的修改信息，其重做日志依次写入重做日志文件的物理文件中。3、当事务启动后产生redolog时，redolog并不是随着事务的提交而写入的，而是在事务执行过程中写入到redolog文件中。4.何时释放当对应事务的脏页写入磁盘后，redolog的使命就完成了，redolog占用的空间可以被重用（覆盖）。5.对应的物理文件默认情况下，对应的物理文件位于数据库的数据目录下。ib_logfile1&ib_logfile2innodb_log_group_home_dir指定日志文件组所在路径。默认的./表示它在数据库的数据目录中。innodb_log_files_in_group指定重做日志文件组中的文件个数，默认2关于文件的大小和个数，通过以下两个参数配置innodb_log_file_size重做日志文件的大小。innodb_mirrored_log_groups指定日志镜像文件组的数量。默认是16。其他的都很重要。重做日志什么时候写入磁盘？前面说过，磁盘是在事情开始后一步步写的。之所以redolog是在事务开始后逐渐写入redolog文件，不一定是在事务提交时，才写入redologcache。原因是redolog有一个缓冲区Innodb_log_buffer，而Innodb_log_buffer的默认大小是8M（这里设置16M），Innodb存储引擎首先将redolog写入innodb_log_buffer。然后通过以下三种方式将innodblogbuffer的logflush到disk1，MasterThread每秒执行一次flushinginnodb_log_buffer到redologfile。2.重做日志在每次事务提交时刷新到重做日志文件中。3、当redologcache的可用空间不足一半时，将redologcache刷新到redolog文件中。可以看出redolog写入磁盘的方式不止一种，特别是对于***这种方式，Innodb_log_buffer到redologfile是MasterThread线程的一个定时任务。因此，重做日志写入磁盘并不一定是随着事务的提交而写入重做日志文件，而是随着事务的开始逐渐开始。另外引用《MySQL技术内幕 Innodb 存储引擎》（第37页）上的原话：即使一个事务还没有提交，Innodb存储引擎仍然会每秒刷新redologcache到redolog文件。这一点一定要知道，因为它可以很好的说明提交大事务的时间也很短。二、回滚日志（undolog）1、作用是保存事务发生前数据的一个版本，可用于回滚。同时可以提供多版本并发控制（MVCC）下的读，即非锁读2.内容逻辑格式的日志，执行undo时，只逻辑上将数据恢复到执行前的状态transaction，而不是对物理页进行操作，这与redolog不同。3、事务开始前，当前版本什么时候产生undolog，undo也会产生redo，保证undolog的可靠性？4.何时释放事务提交后，undolog不能立即删除，而是放入待清理链表中，purge线程判断undolog的日志空间是否可以被其他清理事务在撤销段中使用表中前一个事务之前的版本信息。5、对应的物理文件MySQL5.6之前，undo表空间位于共享表空间的回滚段。共享表空间的默认名称是ibdata，它位于数据文件目录中。MySQL5.6以后，undo表空间可以作为一个独立的文件进行配置，但是需要提前在配置文件中进行配置。数据库初始化后生效，undolog文件数不可更改。如果在数据库初始化之前没有进行相关配置，那么就不能配置为单独的表空间。MySQL5.7以后的独立undo表空间的配置参数如下：innodb_undo_directory=/data/undospace/–undo独立表空间的存放目录innodb_undo_logs=128–回滚段为128KBinnodb_undo_tablespaces=4–如果undo是指定4个undo日志文件used共享表空间，这个共享表空间不仅仅存储undo信息，共享表空间默认在MySQL数据目录下，其属性由参数innodb_data_file_path配置。6.其他undo是事务开始前保存的修改数据的一个版本。当undolog产生的时候，也会伴随着类似保护事务持久化机制的redolog的产生。默认情况下，撤消文件保存在共享表空间中，即ibdatafile文件中。当数据库中发生一些大的事务操作时，会产生大量的undo信息，并全部存储在共享表空间中。因此，共享表空间可能会变得非常大。默认情况下，即undolog使用共享表空间时，“扩容”的共享表空间不会也不能自动收缩。所以mysql5.7以后的“独立undo表空间”的配置是非常有必要的。三、二进制日志（binlog）1、用于复制。在主从复制中，从库使用主库上的binlog进行replay，实现主从同步；用于根据时间点恢复数据库；2.内容逻辑格式中的日志可以简单的看做是执行事务中的SQL语句。但它并不像SQL语句那么简单，而是包含了执行的SQL语句的逆向信息（增删改查），也就是说delete对应的是delete本身及其逆向insert；update对应update执行前后的Version信息；插入对应删除和插入自身。使用mysqlbinlog解析binlog后，一些事情就会水落石出。所以类似oracle的闪回功能可以基于binlog来实现，但实际上都依赖于binlog中的日志记录。3、当一个事务提交时，事务中的SQL语句（一个事物可能对应多条SQL语句）一次性以一定的格式记录在binlog中。这里与redolog的明显区别在于，redolog不一定在事务提交时刷入磁盘，redolog是在事务开始后逐渐写入磁盘的。因此，对于事务的提交，即使是比较大的事务，提交（commit）也是非常快的，但是当开启了bin_log后，比较大的事务的提交可能会变慢。这是因为binlog是在事务提交的时候写一次的，可以通过测试验证。4、什么时候释放binlog，默认保留时间由参数expire_logs_days配置，也就是说对于不活跃的日志文件，在生成时间超过expire_logs_days配置的天数后会被自动删除。5、对应的物理文件配置文件路径为log_bin_basename。binlog日志文件按照指定大小。当日志文件达到指定的最大大小时，它将滚动更新以生成新的日志文件。对于每一个binlog日志文件，通过一个统一的索引文件来组织。6.其他二进制日志的功能之一是恢复数据库。这与重做日志非常相似。很多人把它搞混了，但是两者有本质区别：功能不同：redolog是为了保证事务的持久化，而且是事务级别的，作为binlog恢复的功能，是数据库级别的（的当然也可以精确到交易级别）。虽然两者都有恢复的意思，但对数据的保护程度不同。内容不同：redolog是物理日志，是数据页修改后的物理记录，而binlog是逻辑日志，可以简单的看成是记录SQL语句。另外，这两个日志产生的时间和可以释放的时间在可释放的情况下清理机制是完全不同的。恢复数据时的效率。基于物理日志的redolog恢复数据的效率高于语句逻辑日志的binlog。关于事务提交时redolog和binlog的写入顺序，为了保证主从复制时的主从一致性（当然也包括使用binlog进行时间点恢复），这必须严格一致。MySQL通过两阶段提交过程完成事务一致性，即redolog和binlog的一致性。理论上，redo是先写log，再写binlog，两个log都提交成功（flushedtodisk）才认为事务真正完成。4.小结在MySQL中，对于以上三种类型的日志，每一种都可以细化到足以写一章。这里粗略总结一下三种日志的一些特点和作用，以帮助理解MySQL中的事物和事物背后的基本原理。
