MySQL中已经有了Binlog，为啥还要有Redo Log

参考文章

MySQL中的Binlog和Redo Log虽然都与事务的持久性和可恢复性有关，但它们服务于不同的目的和场景，并且在MySQL的架构中扮演着互补的角色。

Redo Log：
- 目的：Redo Log 主要用于保证InnoDB存储引擎的事务持久性。它确保在系统崩溃的情况下，已经提交的事务不会丢失，这是通过预写日志（Write-Ahead Logging, WAL）机制实现的。
- 工作方式：Redo Log 记录的是事务对数据页所做的物理修改。当事务提交时，这些修改可能还没有写入磁盘上的数据文件，但Redo Log会确保这些修改被写入日志文件中。
- 恢复机制：在发生崩溃后，InnoDB可以利用Redo Log来重做（redo）事务的修改，以此恢复到崩溃前的状态。

如果数据库发生崩溃，InnoDB 在重启时会检查 Redo Log。通过 Redo Log，InnoDB 可以重做（redo）在崩溃前已经提交但可能未写入到数据文件中的事务，确保这些事务的修改得到持久化。

Binlog：
- 目的：Binlog 主要用于记录所有修改了数据库数据的SQL语句，以便用于复制和数据恢复。它是MySQL服务器层的功能，与存储引擎无关。
- 工作方式：Binlog 记录的是逻辑日志，即实际执行的SQL语句或者在RBR模式下记录的行事件。
- 复制和恢复：Binlog 使得MySQL可以实现主从复制，主服务器上的操作可以通过复制Binlog到从服务器并重放来同步数据。同时，Binlog也可以用于点时间恢复（Point-in-Time Recovery），恢复到特定时间点的数据库状态。

在执行更新语句过程，会记录redo log与binlog两块日志，以基本的事务为单位，redo log在事务执行过程中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的写入时机不一样。

为什么两者都需要：

不同的恢复和复制需求：Redo Log 主要用于崩溃恢复，而Binlog用于数据复制和点时间恢复。
性能和优化：Redo Log 的物理日志对于崩溃恢复来说性能更优，因为它直接关联到数据页的状态。Binlog 的逻辑日志则更适合于复制和审计，因为它记录了实际执行的操作。
隔离存储引擎与服务器层：Redo Log 是InnoDB存储引擎特有的，而Binlog 是MySQL服务器层的功能，这种设计使得Binlog可以用于多种存储引擎。

总之，Redo Log 和 Binlog 在MySQL中共同工作，以确保数据的安全性、持久性和一致性，同时提供灵活的数据恢复和复制选项。