一、MySQL常用的几种日志
MySQL主要包含以下几种日志：
- 错误日志
- 查询日志
- 慢查询日志
- 事务日志 [undo日志(回滚日志)、redo日志(重做日志)]
- 二进制日志（binlog日志）
本章主要介绍binlog日志、undo日志、redo日志
二、binlog日志
1. 什么是binlog?
在MySQL的基本架构这篇文章中，我们分享了MySQL的基础架构，其中，binlog日志属于Server层的日志，只能用于归档，没有carsh-safe能力。
MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
2. binlog的作用
主从备份：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到主从数据一致的目的。
数据恢复：通过使用mysqlbinlog工具来使恢复数据。
3. binlog的日志格式
-
语句(statement)：默认的记录格式，每一条会修改数据的sql都会记录在binlog中
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。)
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题).
使用以下函数的语句也无法被复制：
LOAD_FILE()
UUID()
USER()
FOUND_ROWS()
SYSDATE() (除非启动时启用了 --sysdate-is-now 选项)
同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁
行(row)：不记录sql语句上下文相关信息，仅保存哪条记录被修改
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。混合模式(mixed)：是以上两种level的混合使用。
一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的变更。
Mixed日志说明：
在slave日志同步过程中，对于使用now这样的时间函数，MIXED日志格式，会在日志中产生对应的unix_timestamp()*1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。
三、redo日志
1. 什么是redo日志？
redo log叫做重做日志，是用来实现事务的持久性。
该日志文件由两部分组成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log），前者是在内存中，后者在磁盘中。
当事务提交之后会把所有修改信息都会存到该日志中。
是InnoDB引擎独有的日志，属于存储引擎层日志
redo log的大小是固定的，如下图：
说明：
write pos是当前记录的位置，一边写一边后移，写到末尾又从头开始
check point是当前要擦除的位置，同样也是往后移动并且循环，擦除记录，先把日志更新到磁盘中
假设有两张表，如下图：
现在要从银行卡账户转400块到理财账户中，事务过程如下：
start transaction;
select balance from bank where name="zhangsan";
// 生成 重做日志 balance=600
update bank set balance = balance - 400;
// 生成 重做日志 amount=400
update finance set amount = amount + 400;
commit;
上述事务流程图如下：
2. redo log 有什么作用？
mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Boffer Pool(缓冲池)里头，把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。
问题：
但随之二来的问题是，如果还没来的及同步就发生宕机或断电怎么办？上面图中红色的操作还没来得及执行，这样会导致丢失部分已提交事务的修改信息！
解决方法：
引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，系统重启之后在读取redo log恢复最新数据。
四、undo日志
1. 什么是undo日志？
undo log 叫做回滚日志，用于记录数据被修改前的信息。
正好跟前面所说的重做日志所记录的相反，重做日志记录数据被修改后的信息，undo log主要记录的是数据的逻辑变化，为了在发生错误时回滚之前的操作，需要将之前的操作都记录下来，然后在发生错误时才可以回滚。
还用上面那两张表，如下图：
每次写入数据或者修改数据之前都会把修改前的信息记录到 undo log。
2. undo log 有什么作用？
undo log 记录事务修改之前版本的数据信息，因此假如由于系统错误或者rollback操作而回滚的话可以根据undo log的信息来进行回滚到没被修改前的状态。
五、一条更新语句的执行流程（日志两段提交）
六、redo log跟bin log的区别
redo log是InnoDB特有的；
binlog是Server层实现的，所有存储引擎都可以使用redo log是物理日志，记录“某个数据页上的修改”；
binlog是逻辑日志，记录语句的原始逻辑redo log是循环写的，空间固定；
binlog是可以追加写入的，不会覆盖以前的日志
参考资料
Mysql数据库之Binlog日志使用总结
MySQL的binlog日志
MySQL学习笔记 - 1 - 基本架构与日志两阶段提交
Mysql事务实现原理
