redo log是InnoDB实现事务持久性的关键机制，采用WAL技术先写日志再改数据页，确保崩溃后可通过重放日志恢复已提交事务；其为物理日志、循环写入，与binlog在层级、内容、用途和写入方式上均不同，通过innodb_log_file_size等参数可优化管理。
redo log（重做日志）是 MySQL InnoDB 存储引擎中用于保证事务持久性的重要机制。它记录了数据页的物理修改，确保在数据库发生崩溃或意外宕机后，未写入磁盘的已提交事务能够被恢复。
redo log 的作用
InnoDB 使用 WAL（Write-Ahead Logging，预写日志）技术，所有对数据的修改必须先写日志再改内存中的数据页。这样做的好处是：
- 避免每次事务提交都直接刷新数据页到磁盘，提升性能
- 即使系统崩溃，只要 redo log 还在，就可以通过重放日志恢复已提交的事务
- 保障 ACID 中的 D（Durability，持久性）特性
redo log 的工作原理
redo log 是一个环形缓冲区（log buffer），其内容会定期刷盘到磁盘上的 redo log 文件（通常为 ib_logfile0 和 ib_logfile1）。
- 当事务执行更新操作（INSERT、UPDATE、DELETE）时，InnoDB 会把“某数据页的某个偏移位置修改了什么值”记录到 redo log buffer
- 事务提交时，redo log buffer 中的内容会根据策略（如 innodb_flush_log_at_trx_commit 设置）同步或异步写入磁盘
- 后台线程会逐步将脏页刷回数据文件，这个过程可以延迟，但 redo log 必须先落盘
与 binlog 的区别
很多人容易混淆 redo log 和 binlog，它们有本质不同：
- 层级不同：redo log 是 InnoDB 引擎层的日志；binlog 是 MySQL Server 层的日志
- 内容不同：redo log 记录的是物理级别的页修改；binlog 记录的是逻辑操作，如 SQL 语句或行变更
- 用途不同：redo log 主要用于崩溃恢复；binlog 用于主从复制和数据审计
- 写入方式不同：redo log 是循环写；binlog 是追加写
配置与管理要点
可以通过以下参数优化 redo log 行为：
- innodb_log_file_size：单个 redo log 文件大小，越大能支持更大并发，但恢复时间变长
- innodb_log_files_in_group：redo log 文件数量，一般为 2
- innodb_flush_log_at_trx_commit：控制事务提交时日志刷盘策略，值为 1 最安全（每次提交都刷盘），0 或 2 可提升性能但有丢数据风险
基本上就这些。redo log 是 InnoDB 实现高可靠性和高性能的关键组件，理解它有助于排查性能问题和设计容灾方案。
