重做日志（Redo Log）
redo log是记录事务过程中的任何修改，这些修改在事物提交之前数据是不会真真写入到磁盘的
-
写前日志（Write-Ahead Logging, WAL）：在数据被写入数据库页之前，所有修改都会先写入到重做日志中。这个过程称为写前日志策略，确保即使在数据库突然崩溃的情况下，所有提交的事务都可以通过重播日志记录重新构建。
-
日志缓冲区（Log Buffer）：修改首先被记录到内存中的日志缓冲区，然后在适当的时候异步写入到磁盘的重做日志文件中。
先写到缓存区，以为如果直接写到磁盘，IO是比较慢的
-
日志刷新（Log Flushing）：为了保证持久性，在每个事务提交时，相关的重做日志必须从日志缓冲区刷新到磁盘。这一步是通过调用操作系统的同步I/O操作来完成的。
二进制日志（Binary Log）
binary log是记录提交事务后的最终结果
二进制日志是MySQL服务器级别的日志，记录了所有修改数据库内容的语句（如INSERT, UPDATE, DELETE），以及DDL语句如CREATE TABLE，DROP TABLE等：
- 复制和恢复：二进制日志主要用于复制和数据恢复。在复制配置中，二进制日志用于在主服务器上记录所有更改，并将这些更改传播到一个或多个从服务器。
- 点对点恢复：在发生系统故障后，二进制日志可以用来对数据库执行点对点的恢复。
redo log 和bin log的区别
- redo log是记录事务中的变更，而bin log是事务提交后的最终结果，比如账户A转账给账户B 100元，开启事务 --> A - 100 --> B --100 --> 提交事务， A - 100：记录redo log（持久化），bin log也会记录但不会持久化（可以理解成没有记录），B - 100: 同前一个步骤。提交事务：记录redo log（持久化）
- Redo log是为了故障后恢复事务状态，undo log是为了数据库的复制（比如主从复制）和点对点恢复
日志刷新策略
从缓存区将数据写入磁盘
MySQL提供了多种日志刷新策略来平衡性能与数据安全性之间的权衡：
- 同步提交：最安全，但性能较低。事务的每次提交都要求重做日志物理写入到磁盘。
- 异步提交：提高性能，但在极端情况下可能会丢失刚提交的事务数据