根本原因是事务提交后数据页尚未刷盘，但需保证持久性；redo log通过顺序写磁盘日志兑现“已提交即不丢”的承诺，避免随机写数据页导致的性能差与部分页写入风险。
MySQL 需要 Redo Log，根本原因就一条：**事务提交后，数据页还没写到磁盘，但用户已经认为“数据不会丢”了——这个承诺靠 Redo Log 落盘来兑现。**
为什么不能直接把数据页刷盘？
直接写数据页是随机 I/O：你要更新第 100 号页、第 2000 号页、第 50 号页……磁头来回跳，慢；断电时还容易只写了一半（Partial Page Write），整个页损坏。
Redo Log 是顺序追加写：日志文件（如 /var/lib/mysql/ib_logfile0）永远往末尾 append，一次写一小段，快且原子；即使断电，也只会丢最后没 flush 的那点日志，不会破坏已有结构。
- 随机写数据页 ≈ 每次翻三本不同书的第 7 页、第 42 页、第 108 页
- 顺序写
Redo Log≈ 只在同一个本子上从前往后抄，一页写满翻下一页
innodb_flush_log_at_trx_commit 怎么影响持久性？
这个参数决定“事务提交”和“日志落盘”之间的绑定强度，直接影响崩溃后是否丢数据：
-
=1（默认）：每次COMMIT都调用fsync()→ 日志真落盘 → 强持久，但吞吐受限 -
=0：日志只留在 OS 缓存，每秒刷一次 → 断电可能丢最多 1 秒事务 -
=2：COMMIT时仅write()到 OS 缓存，不fsync()；后台每秒fsync()一次 → 折中，但若 OS 崩溃（非 MySQL 崩溃）仍可能丢日志
别盲目设为 0 或 2 —— 这不是性能开关，是持久性 SLA 选择。金融类业务必须用 1；日志类异步写入可考虑 2。
崩溃恢复时，Redo Log 具体怎么重做？
MySQL 启动时自动触发崩溃恢复（Crash Recovery），流程不依赖用户干预：
- 扫描所有
ib_logfile*，定位 checkpoint 位置（即“已确认刷盘到数据文件的最远点”） - 从 checkpoint 开始重放后续所有已提交事务的
Redo Log记录（物理操作：如“页 1234，偏移 56，写入 4 字节值 0xABCDEF00”） - 重做过程中，会重建 Buffer Pool 中缺失或过期的脏页，最终让内存状态与日志一致
- 未提交事务的
Redo Log不会被重做，其修改由Undo Log回滚（这是两套日志协同工作的关键）
注意：Redo Log 重做的是“已提交但未刷盘的数据变更”，不是 SQL 语句本身 —— 所以它不保证 binlog 一致性，主从延迟或 GTID 错位需额外处理。
循环写 Redo Log 文件，会不会覆盖还没用的日志？
不会，但前提是 checkpoint 推进及时。InnoDB 用 innodb_log_file_size × innodb_log_files_in_group 控制总日志空间（例如 2×1GB = 2GB）。当写满时，会切换文件并尝试推进 checkpoint。
如果写压力极大 + 脏页刷盘太慢（比如磁盘慢、innodb_io_capacity 设太低），checkpoint 落后太多，就会触发“active log too large”警告，甚至阻塞新事务 —— 这时不是日志机制有问题，而是 I/O 能力跟不上写入节奏。
真正容易被忽略的点：日志文件大小不能随便调大。过大的 ib_logfile* 会导致崩溃恢复时间显著增加（因为要扫描更多日志），尤其在大实例上，1GB 和 4GB 的恢复耗时可能差数分钟。
