后端一个疑问

也可以做，但是binlog保存的是全量的数据。他不知道哪些页属于脏页（写入物理页但没写回磁盘），使用binlog恢复我的理解是需要使用所有binlog数据恢复。而redolog记录了哪些页为脏页。重做的时候只需要重做这些数据就行。效率会高很多

binlog是记录的是sql级别的日志，redolog是物理级别的日志，重做肯定是redolog快

redolog和undolog是事务中的，redolog用来回滚，存的是逻辑数据，undolog用来事务判断读已提交和可重复读这两个隔离级别。而binlog是全量数据，可以用来监听数据库变化和恢复。总之记住，binlog是server层的，redolog和undolog是事务中的，所以是存储引擎层的，server层和存储引擎层完全是两套东西

首先，需要明确 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 的操作指导，进行页面数据恢复。 其实，当你觉得一个东西不需要的时候，想象一下把它去掉，这个系统是否可以保证正确。

我认为是redo log更可靠，特别是对断电这种突然中断的情况： 1. binlog是在事务提交好刷盘，redolog是在事物提交前刷盘 2. redo log划分的更细，每个SQL语句可能针对多个数据页的数据进行修改，对于每个数据页修改划分为一个最小单位（mini-Transaction），对于事务执行期间服务器崩溃时的状态都可以恢复。

评论区还没有说清楚的一点是，mysql 的redo log是一个环形缓存的，大小一般为5g，写满了会从投开始写。而binlog没有上限。 当然数据库并不是一定要求记录逻辑日志binlog，很多分布式数据库已经实现了以物理日志来同步，将物理日志空间不设为环形，进而大大提高性能

binlog是一条一条的增删改的记录，redolog记录的是物理页面的修改。如果使用binlog的话，需要一条一条执行sql，redolog的话基于物理页要快一些。你也可以拓展一下，就好像redis中两个持久化机制，一个rdb一个aof，rdb一般记录的是全量的物理数据，aof记录的一条一条的增删改，redis里面使用rdb恢复或者是备份也是很快的。

binlog不能给脏页刷盘

binlog并不是一个原子的操作，一条binlog可能对应多条redo log，如果只使用binlog，那么需要先落盘binlog，再落盘数据，如果此时数据只落盘了一部分就挂了，恢复时无法通过binlog进行重做。

但是主从不也是用的binlog吗

用binlog也行，满足两个前提，1，MySQL一开始使用的时候就开启binlog，且中途无异常，2，先把数据库中的数据清空

个人理解，binlog慢

redo log：解决事务持久性 & crash recovery（快，物理级别）。 binlog：用于主从复制、备份恢复（逻辑级别，跨存储引擎）。 再了解一下两阶段提交你就懂了