redo log是InnoDB实现事务持久性的关键机制，通过记录数据页的物理修改并顺序写入磁盘文件（ib_logfile0和ib_logfile1），在系统崩溃后可前滚恢复已提交事务；事务提交时，redo log必须落盘才算完成，由innodb_flush_log_at_trx_commit参数控制刷盘策略（1最安全，0或2性能更高但有丢失风险）；redo log循环写入固定大小文件，需等待脏页刷新后才能覆盖，合理设置大小可避免写阻塞。
MySQL通过InnoDB存储引擎的redo log（重做日志）来确保事务的持久性，即使在系统崩溃后也能恢复已提交的数据。redo log是实现ACID中D（Durability，持久性）的关键机制。
什么是redo log
redo log是InnoDB存储引擎特有的物理日志，记录的是“对数据页做了什么修改”，比如“在某数据页上将某个字段的值从A改成了B”。它顺序写入磁盘上的两个文件（ib_logfile0和ib_logfile1），具有高写入性能。
与binlog不同，redo log是InnoDB内部使用的、用于崩溃恢复的物理日志，而binlog是逻辑日志，用于主从复制和审计。
redo log如何保证事务安全
当一个事务提交时，InnoDB会确保该事务产生的redo log被写入磁盘，这个过程称为“write and flush”。只要redo log落盘，即使此时数据库宕机，重启后也能根据这些日志重新应用更改，从而保证已提交事务不会丢失。
- 事务执行过程中，修改的数据先写入Buffer Pool，同时生成对应的redo log并写入redo log buffer
- 事务提交时，redo log buffer中的日志会被刷入磁盘的redo log文件（由innodb_flush_log_at_trx_commit参数控制刷盘策略）
- 一旦redo log持久化成功，事务就被认为是“持久化”的，即使数据页还没写回磁盘
- 如果系统崩溃，重启后InnoDB会读取redo log，将已提交但未写入数据文件的更改重新执行一遍（即“前滚”）
关键配置：innodb_flush_log_at_trx_commit
这个参数直接影响redo log的刷盘行为和数据安全性：
- 值为1：每次事务提交都必须将redo log写入磁盘（最安全，默认值）。即使宕机也不会丢失任何已提交事务
- 值为0：每秒写一次磁盘，事务提交时不强制刷盘。可能丢失最多1秒的事务
- 值为2：每次提交写到操作系统缓存，每秒刷一次磁盘。操作系统崩溃可能丢失数据，但MySQL自身崩溃不会
生产环境建议保持默认值1，以确保最高级别的数据安全。
redo log的循环写入机制
redo log文件大小固定且数量有限（通常两个），采用环形方式写入。当写满时，InnoDB需要确保对应的数据页已经刷新到磁盘（checkpoint机制），然后才能覆盖旧的日志。
如果写入速度超过脏页刷新速度，可能导致写入阻塞，因此合理设置redo log大小（如每个文件1GB，共4个）有助于提升稳定性。
基本上就这些。redo log的存在让MySQL能在故障后恢复到崩溃前的状态，真正实现了事务的持久性保障。不复杂但容易忽略细节。
