redo log是InnoDB通过WAL机制实现持久性的物理日志，事务提交时写入磁盘，崩溃后重启恢复数据。
MySQL 的持久化机制主要依赖于 InnoDB 存储引擎的 redo log（重做日志）来保证事务的持久性。当事务提交后，即使系统崩溃，已提交的数据也不会丢失，这正是通过 redo log 实现的。
redo log 是什么？
redo log 是 InnoDB 特有的物理日志，记录的是“在哪个数据页上做了什么修改”。它采用顺序写入的方式，先写日志再写数据页（即 WAL：Write-Ahead Logging），大幅提升写性能。
redo log 是循环写入的，大小固定（默认两个文件，共 48MB，由 innodb_log_file_size 和 innodb_log_files_in_group 控制）。当日志空间用完时，会触发检查点（Checkpoint），将脏页刷回磁盘，释放日志空间。
redo log 如何保障持久性？
事务提交时，InnoDB 会确保 redo log 被写入磁盘（由 innodb_flush_log_at_trx_commit 参数控制），之后即使数据库宕机，重启时也能通过重放 redo log 恢复未刷盘的数据。
- 值为 1：每次事务提交都同步写入磁盘（最安全，默认值）
- 值为 0：每秒写入一次，事务提交不触发写入（性能高但可能丢失一秒数据）
- 值为 2：每次提交写入操作系统缓存，每秒刷盘（折中方案）
checkpoint 与恢复机制
为了防止 redo log 写满，InnoDB 会定期执行 checkpoint，将已确认的脏页从内存刷到磁盘，并更新 redo log 的可覆盖位置。
MySQL 重启时，InnoDB 会读取 redo log，从最后一个 checkpoint 开始重放所有已提交但未落盘的修改，这个过程称为崩溃恢复（Crash Recovery）。
与其他日志的区别
注意区分 redo log 和 binlog：
- redo log：InnoDB 层的物理日志，用于崩溃恢复，循环使用
- binlog：Server 层的逻辑日志，用于主从复制和数据恢复，追加写入
两者通过两阶段提交（Two-Phase Commit）保持一致性，确保 crash-safe。
基本上就这些。redo log 是 MySQL 实现持久性和高性能写入的核心机制之一，理解其工作原理有助于优化数据库配置和故障排查。
