binlog 可以给备库使用，也可以保存起来用于恢复数据库历史数据。它是实现在 server 层的，所有引擎可以共用。redo log 是 InnoDB 特有的日志，用来支持 crash-safe 能力。

MySQL 事务的两阶段提交，指的就是在事务提交的时候，分成 prepare 和 commit 两个阶段。

如图所示为一个事务的执行流程，你在最后三步可以看到，redo log 先 prepare 完成，再写 binlog，最后才进入 redo log commit 阶段。

image.png

redo log 和 binlog 是怎么关联起来的?

它们有一个共同的数据字段，叫 XID。崩溃恢复的时候，会按顺序扫描 redo log：

  • 如果碰到既有 prepare、又有 commit 的 redo log，就直接提交；
  • 如果碰到只有 parepare、而没有 commit 的 redo log，就拿着 XID 去 binlog 找对应的事务。

为什么还要两阶段提交呢？干脆先 redo log 写完，再写 binlog。崩溃恢复的时候，必须得两个日志都完整才可以。是不是一样的逻辑？

对于 InnoDB 引擎来说，如果 redo log 提交完成了，事务就不能回滚（如果这还允许回滚，就可能覆盖掉别的事务的更新）。而如果 redo log 直接提交，然后 binlog 写入的时候失败，InnoDB 又回滚不了，数据和 binlog 日志又不一致了。

两阶段提交就是为了给所有人一个机会，当每个人都说“我 ok”的时候，再一起提交。

redo log

作用：用来恢复提交事务修改页的操作，用来保证事务的持久性。
组成：内存中的重做日志缓冲（redo log buffer）,其是易失的；重做日志文件（redo log file）是持久的

按顺序读写

binlog

undolog

作用：回滚行记录到某个特定版本，用来帮助事务回滚和MVCC功能

随机读写