redo log是事务持久化的基石，因其采用顺序写替代随机写，通过wal机制确保事务提交时仅需日志落盘即可认定成功，后续脏页刷盘可异步进行；它记录页号、偏移量及物理变更，崩溃后依lsn重放恢复数据。
redo log 对数据持久化重要，是因为它用顺序写替代随机写，把“事务提交必须成功”这件事从慢的磁盘随机 I/O 中解耦出来——只要 redo log 落盘，事务就算真正落地；后续脏页刷盘可以异步、批量、延迟，不影响用户感知。
redo log 是 WAL（Write-Ahead Logging）的物理实现载体
WAL 不是口号，是强制约束：任何数据页修改前，对应物理变更必须先记入 redo log。这直接决定了崩溃后能否恢复。
- 没
redo log，InnoDB 每次COMMIT都得等所有相关数据页同步刷盘（随机写），性能崩塌，且断电即丢数据 - 有
redo log，COMMIT只需确保日志落盘（顺序写），哪怕 Buffer Pool 里改过的页还在内存、甚至服务器立刻断电，重启后也能重放日志补上 - 注意：
redo log记录的是「页号+偏移+修改前后值」这类物理变更，不是 SQL，也不是行级逻辑，所以重放快、定位准
innodb_flush_log_at_trx_commit=1 并非可选，而是持久性底线
这个参数控制事务提交时 redo log 是否真正写入磁盘（而非仅到 OS page cache）。设为 1 才满足 ACID 的 D（Durability）。
-
0：日志只写到内存，MySQL 崩溃就全丢（最多丢 1 秒事务） -
2：日志写到 OS page cache，操作系统崩溃或断电仍可能丢失 -
1：调用fsync()强制刷盘，保证日志在磁盘介质上——这是唯一能扛住服务器断电的配置 - 别被“后台每秒刷一次”误导：那是针对未提交事务的缓冲刷新，不能替代
COMMIT时刻的强制落盘
redo log 文件大小和数量直接影响恢复时间与切换开销
ib_logfile0 和 ib_logfile1 是循环使用的物理文件，大小由 innodb_log_file_size 控制，默认太小（48MB）会导致频繁 checkpoint 和日志切换。
- 太小（如 128MB）：日志很快写满，触发频繁 checkpoint，拖慢写入，还可能因切换卡顿影响高并发
- 太大（如 4GB）：单次崩溃恢复要扫描更多日志，启动变慢；但写压力大时更稳
- 调整需停机：改
innodb_log_file_size必须 shutdown → 删除旧日志文件 → 启动，否则 InnoDB 拒绝启动 - 建议：OLTP 场景从 1GB 起调，观察
SHOW ENGINE INNODB STATUS中的 Log sequence number 和 checkpoint age
崩溃恢复时，redo log 是唯一可信的数据来源
MySQL 重启后第一件事不是读表空间，而是扫描 redo log 文件，比对每个数据页头的 LSN 和日志中的 LSN：
- 若页 LSN
- 若页 LSN ≥ 日志最新 LSN：跳过，该页已是最新状态
- undo log 在这时只用于回滚未提交事务，不参与已提交事务的恢复——那是
redo log的职责 - 别指望 binlog：它不参与崩溃恢复，只用于主从复制或 PITR（基于时间点恢复），且是逻辑日志，无法精确还原页级状态
redo log 和 Buffer Pool 的耦合深度——它不仅记录数据页修改，也记录 undo 页修改；不仅保障数据不丢，也保障回滚信息不丢。一旦 redo log 损坏或配置不当，整个 WAL 链条就断了，没有“万一”。
