binlog二进制日志是mysql-server层的，主要是做主从复制，时间点恢复使用
redo log重做日志是InnoDB存储引擎层的，用来保证事务安全
undo log回滚日志保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。select如果没有特定加锁的话就是快照读，用到了undolog，而insert delete和update都是当前读，与这个日志关系不大。
redo log
redo log在事务没有提交前，每一个修改操作都会记录变更后的数据，保存的是物理日志->数据
防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性.
redo log只是先写入Innodb_log_buffer，定时fsync到磁盘
bin log
binlog只会在日志提交后，一次性记录执行过的事务中的sql语句以及其反向sql(作为回滚用)，保存的是逻辑日志->执行的sql语句
undo log事务开始之前，将当前版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性，保存的是逻辑日志->数据前一个版本
两者的区别
基于redo log直接恢复数据的效率 高于 基于binlog sql语句恢复
binlog不是循环使用，在写满或者重启之后，会生成新的binlog文件，redo log是循环使用。
binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用。
两阶段提交
两阶段提交
最后，那么当我执行一条 update 语句时，redo log 和 binlog 是在什么时候被写入的呢？这就有了我们常说的「两阶段提交」：
写入：redo log（prepare）
写入：binlog
写入：redo log（commit）
为什么 redo log 要分两个阶段： prepare 和 commit ？redo log 就不能一次写入吗？
我们分两种情况讨论：
先写 redo log，再写 binlog
先写 binlog，再写 redo log
1、先写 redo log，再写 binlog
这样会出现 redo log 写入到磁盘了，但是 binlog 还没写入磁盘，于是当发生 crash recovery 时，恢复后，主库会应用 redo log，恢复数据，但是由于没有 binlog，从库就不会同步这些数据，主库比从库“新”，造成主从不一致
2、先写 binlog，再写 redo log
跟上一种情况类似，很容易知道，这样会反过来，造成从库比主库“新”，也会造成主从不一致
而两阶段提交，就解决这个问题，crash recovery 时：
如果 redo log 已经 commit，那毫不犹豫的，把事务提交
如果 redo log 处于 prepare，则去判断事务对应的 binlog 是不是完整的
是，则把事务提交
否，则事务回滚
两阶段提交，其实是为了保证 redo log 和 binlog 的逻辑一致性。
