首先，需要明确 MySQL 中这两种 log 存放的是什么数据。 binlog 是 MySQL 自己的日志，它里面存放的是二进制格式的 SQL 语句 或 变化的每行 SQL 信息。（具体要看 binlog_format 是 STATEMENT 还是 ROW）为了简化讨论，就把它当作存放了一堆 SQL 的二进制文件。 redo log 是 InnoDB 的日志，InnoDB 是 MySQL 的一种可选引擎。redo log 里面存放的是对 InnoDB 数据页面的「修改动作」，可以抽象成把某个字节从 X 改成 Y。由于它只记录操作，所以 redo log 并不清楚这些操作在逻辑上对应什么。 （数据页面也简单解释下，可以想象成把表里的数据，一行接一行的排列到一个大的文件中。修改数据页面的动作，实际上就是在修改行内的数据。） 基本概念对齐以后，我们来考虑没有 redo log 会怎么样。我们要知道 binlog 和 磁盘上的数据页 从物理上没办法保证同时写入完成，总归会有先后。那么我们写入 binlog 后，数据页面刷到一半，机器断电了，我们如何把数据页从茫茫字节中，恢复到之前的内容呢？（这里还涉及一个 doublewrite buffer 的概念，但为了聚焦问题，先假设一次性刷写能完整刷写一个页面） 可以简单认为，MySQL 决定一个事务是否成功提交，取决于 binlog。假设 binlog 是完整的，存储引擎无论如何都得把这条 binlog 对应的记录还原回来，否则事务就丢失了。同时 MySQL 主备复制也是依赖 binlog，也就是 binlog 具有 “一票否决权”。而 redo log 是 InnoDB 指导自己如何恢复数据的。 从我的表述来看，redo log 和 binlog 必须保证一致。要么都有，要么都没有。这点从物理上无法保证，但是从逻辑上可以。redo log 先写入本次操作，并记录 “type” 为 prepare；这时写入 binlog，再写入一条 redo log commit 记录。 假设1：只有 redo log prepare，没有 binlog。说明事务没有提交，我需要根据 redo log prepare 的操作指导，保证数据页的正确性。 假设2：有 binlog，没有 redo log commit。说明事务是正确提交的，只是 redo commit 没来得及写入，我需要根据 redo log prepare 的操作指导，进行页面数据恢复。 其实，当你觉得一个东西不需要的时候，想象一下把它去掉，这个系统是否可以保证正确。