InnoDB 通过 redo 日志保证事务持久性：事务提交后，修改先写入 redo 日志（物理逻辑日志，顺序写、高效紧凑），崩溃时从 checkpoint 开始重放已提交事务的变更；关键参数 innodb_flush_log_at_trx_commit=1 可确保强持久性。
InnoDB 通过 redo 日志（重做日志）来保证事务的持久性。持久性是指：一旦事务提交（COMMIT），即使数据库发生崩溃，该事务对数据的修改也必须永久保存、不可丢失。InnoDB 不直接将数据页刷盘，而是先写 redo 日志，再异步刷数据页；崩溃恢复时，用已落盘的 redo 日志重放（replay）未写入磁盘的数据变更，从而确保已提交事务不丢失。
redo 日志的核心作用：记录物理变更
redo 日志记录的是“物理逻辑日志”——不是 SQL 语句，也不是完整的数据页，而是针对某个表空间中某一页的某个偏移量上的 字节 修改（如“把第 5 号页 offset=100 处的 4 字节从 0x1234 改为 0x5678”）。这种细粒度记录方式高效、紧凑，且与恢复强绑定。
- 写入速度快：顺序写磁盘（通常在 ib_logfile* 文件中），避免随机 I/O
- 无需加锁：每个事务写自己的 redo log buffer，由后台线程统一刷盘
- 只记录已提交或可能提交的变更：未提交事务的日志也会写入，但崩溃恢复时会结合 undo 日志回滚未提交部分
redo 日志的生命周期：从内存到磁盘再到应用
事务执行过程中，InnoDB 将修改操作先写入内存中的 redo log buffer；随后按策略刷入磁盘上的 redo log file（默认两个文件轮转使用）；最后在 checkpoint 机制推动下，脏页被刷新到数据文件（ibd）中。
- log buffer 刷盘时机：事务提交时（innodb_flush_log_at_trx_commit = 1）、buffer 占满约 1/2、主线程每秒刷一次、或脏页刷新前强制刷
- log file 循环写入：日志空间固定（由 innodb_log_file_size × innodb_log_files_in_group 决定），写满后从头覆盖，前提是对应位置的变更已刷入数据文件（即 checkpoint 已推进）
- checkpoint 推进：表示“该位置之前的日志所对应的脏页，已全部刷盘”，是日志复用和崩溃恢复起点的关键标记
崩溃恢复：靠 redo 日志重放保障持久性
MySQL 启动时若检测到异常关闭，会自动进入恢复流程：读取 redo 日志，从最近一个 checkpoint 开始扫描，对其中所有已提交事务的修改进行重放（apply），将变更重新写入 Buffer Pool，并最终刷入磁盘数据文件。
- 只重放 已提交事务 的日志（未提交的会被后续 undo 回滚）
- 重放过程不依赖 binlog，完全由 InnoDB 自主完成
- 即使数据页损坏或未写入，只要 redo 日志完整，就能重建出正确状态
关键参数影响持久性行为
实际部署中，innodb_flush_log_at_trx_commit 是控制持久性强度的核心参数：
- =1（默认）：每次事务提交都触发一次 fsync 到磁盘，最安全，满足 ACID 持久性要求
- =0：每秒一次 fsync，事务提交仅写入 log buffer，崩溃可能丢失 1 秒内提交的事务
- =2：每次提交写入 OS cache，但不 fsync；操作系统 崩溃可能丢日志，但 MySQL 崩溃不丢
生产环境强烈建议保持为 1，尤其涉及资金、订单等关键业务。
