MySQL redo log 与 binlog 的区别
1. 什么是redo log？
redo log又称重做日志文件，用于记录事务操作的变化，记录的是数据修改之后的值，不管事务是否提交都会记录下来。在实例和介质失败（media failure）时，redo log文件就能派上用场，如数据库掉电，InnoDB存储引擎会使用redo log恢复到掉电前的时刻，以此来保证数据的完整性。
1.1 redo日志文件名
每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文件，如默认的ib_logfile0和ib_logfile1。
1.2 影响redo log参数
-
innodb_log_file_size：指定每个redo日志大小，默认值48MB -
innodb_log_files_in_group：指定日志文件组中redo日志文件数量，默认为2 -
innodb_log_group_home_dir：指定日志文件组所在路劲，默认值./，指mysql的数据目录datadir -
innodb_mirrored_log_groups：指定日志镜像文件组的数量，默认为1，此功能属于未实现的功能，在5.6版本中废弃，在5.7版本中删除了。
以下显示了一个关于redo日志组的配置：
mysql> show variables like 'innodb%log%';
+----------------------------------+------------+
| Variable_name | Value |
+----------------------------------+------------+
...
| innodb_log_file_size | 2147483648 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
...
+----------------------------------+------------+
15 rows in set (0.00 sec)
1.3 redo log大小怎么设置？
redo log文件的大小设置对于InnoDB存储引擎的性能有着非常大的影响。
-
设置的太大
设置很大以后减少了checkpoint，并且由于redo log是顺序I/O，大大提高了I/O性能。但是如果数据库意外出现了问题，比如意外宕机，那么需要重放日志并且恢复已经提交的事务，如果日志很大，那么将会导致恢复时间很长。甚至到我们不能接受的程度。 -
设置的太小
当一个日志文件写满后，innodb会自动切换到另外一个日志文件，而且会触发数据库的检查点（checkpoint），这会导致innodb缓存脏页的小批量刷新，会明显降低innodb的性能。
-
怎么设置？
参考官方文档'Optimizing InnoDB Redo Logging'章节-
把重做日志文件设置很大，甚至与缓冲池一样大。当InnoDB将重做日志文件写满时，它会触发数据库的检查点，把缓冲池的脏数据写入磁盘。小的重做日志文件会导致许多不必要的磁盘写入。虽然在以前版本中，大的重做日志文件导致冗长的恢复时间，但现在恢复速度更快，可以放心地使用大型重做日志文件。
-
考虑增加日志缓冲区的大小。 大型日志缓冲区可以在事务提交之前运行大型事务，而无需将日志写入磁盘。 因此，如果您有更新，插入或删除许多行的事务，则使日志缓冲区更大可以节省磁盘I/O. 使用
innodb_log_buffer_size配置选项配置日志缓冲区大小。 -
设置
innodb_log_write_ahead_size参数，表示redo log写前的块大小。InnoDB以512字节一个block的方式对齐写入ib_logfile文件，但文件系统一般以4096字节为一个block单位。如果即将写入的日志文件块不在OS Cache时，就需要将对应的4096字节的block读入内存，修改其中的512字节，然后再把该block写回磁盘。当 当前写入文件的偏移量不能整除该值时，则补0，多写一部分数据。这样当写入的数据是以磁盘block size对齐时，就可以直接write磁盘，而无需read-modify-write这三步了。
-
2. 什么是binlog
binlog记录了对MySQL数据库执行更改的所有操作，但是不包括SELECT和SHOW这类操作，因为这类操作对数据本身并没有修改。然后，若操作本身并没有导致数据库发生变化，那么该操作也会写入二进制日志。例如：
root@localhost [(none)] 08:30:14>set binlog_format = 'STATEMENT';
root@localhost [(none)] 08:30:26>use test;
Database changed
root@localhost [test] 08:30:33>select * from account;
+----------+---------+
| acct_num | amount |
+----------+---------+
| 138 | 14.98 |
| 141 | 1937.50 |
| 97 | -100.00 |
+----------+---------+
3 rows in set (0.00 sec)
root@localhost [test] 08:30:53>show master status;
+----------------------+----------+--------------+------------------+--------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+----------------------+----------+--------------+------------------+--------------------------------------------+
| my3306_binlog.000052 | 471 | | | e4382832-949d-11e8-97ba-080027793430:1-205 |
+----------------------+----------+--------------+------------------+--------------------------------------------+
root@localhost [test] 08:31:04>update account set acct_num=139 where amount=14;
Query OK, 0 rows affected (0.01 sec)
Rows matched: 0 Changed: 0 Warnings: 0
root@localhost [test] 08:31:35>show binlog events in 'my3306_binlog.000052';
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+----------------------+-----+----------------+-----------+-------------+---------------------------------------------------------------------+
| my3306_binlog.000052 | 4 | Format_desc | 1003306 | 123 | Server ver: 5.7.23-log, Binlog ver: 4 |
| my3306_binlog.000052 | 123 | Previous_gtids | 1003306 | 194 | e4382832-949d-11e8-97ba-080027793430:1-204 |
| my3306_binlog.000052 | 194 | Gtid | 1003306 | 259 | SET @@SESSION.GTID_NEXT= 'e4382832-949d-11e8-97ba-080027793430:205' |
| my3306_binlog.000052 | 259 | Query | 1003306 | 331 | BEGIN |
| my3306_binlog.000052 | 331 | Table_map | 1003306 | 384 | table_id: 108 (test.account) |
| my3306_binlog.000052 | 384 | Update_rows | 1003306 | 440 | table_id: