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