Innodb 中的 redo log 个人理解

在学习中碰到了一个问题，下面是我的思考内容。

MySQL innodb 中的 redo log 的存在意义，为什么需要新加一个日志，如果没有 redo log，两阶段提交就可以改成直接 commit，岂不美滋滋？

比较通用的说法：redo log 的存在，为 innodb 保证了在数据库发生异常重启时，之前提交的记录不会丢失，这个称为 crash-safe。

那么问题来了：如果只有一个 binlog，为什么就实现不了 crash-safe 呢？毕竟事务在提交之前也是保证 binlog 是写入成功的，而 crash-safe 是保证数据在事务提交后（Innodb 是 WAL 模式，日志写完就可以提交事务，不需要在业务数据写入磁盘后），业务逻辑没有写入磁盘前，数据库异常宕机，也不会出现数据丢失。

为什么 binlog 不可以？有一个原因是其内部存储的内容并不足以满足 innodb 的需求，单纯的 binlog 并不能判断出来哪些数据是在提交后没写入磁盘的。那么如果将 binlog 改写，是否可以不需要 redo log 呢，我的理解是可以的，不过这样其实就是重新做了一个 redo log 出来，而且 binlog 在 MySQL 中的使用是非常广泛的，进行 binlog 的改造还需要其他已有功能支持，所以 innodb 进行了 redo log 的添加。