Redo Log
Redo Log 是 InnoDB 保证已提交修改在崩溃后仍可重做的关键日志，用来支撑事务持久性和存储引擎恢复。
#type / concept
#status / growing
#tech / dev / backend
#resource / database
#resource / mysql
[!info] related notes
Redo Log
一句话定义
Redo Log 是 InnoDB 为了在崩溃恢复时把已提交但尚未刷盘的修改重新做出来而维护的重做日志。
它要解决什么问题
InnoDB 修改数据时，不会每次都立刻把最终数据页完整写回磁盘。
这样做对性能有利，但会带来一个问题：
- 事务已经提交成功
- 但对应数据页还在内存里或只刷了一部分
- 这时如果宕机，提交成功的结果怎么保住
Redo Log 就是为这个问题存在的。它让数据库可以先安全记录“这次修改应该存在”，后面再异步把数据页慢慢刷回去。
核心机制 / 工作原理
1. 重做日志关心的是“已提交修改怎么补回来”
Redo Log 关注的不是“如何撤销”，而是：
- 已经提交成功的修改，如果没来得及写入最终页，恢复时如何重新做出来
所以它面向的是崩溃后的恢复，不是事务失败时的回滚。
2. 提交成功不等于数据页已经写完
更常见的路径是：
- 先在内存里修改页
- 记录对应的 redo 信息
- 提交时确保 redo 足够安全地落盘
- 后续再把数据页异步刷回磁盘
这样数据库才能同时兼顾：
- 提交语义的可靠性
- 随机页写入的性能成本
3. Redo Log 的核心价值是支撑崩溃恢复
如果数据库在数据页刷盘前崩溃：
- 恢复阶段可以根据 Redo Log 判断哪些修改已经算成功提交
- 然后把这些修改重新应用到相应的数据页
所以它本质上是在回答：
已提交事务的最终结果，如何在崩溃后被恢复出来。
最小例子 / 最小场景
一次订单状态更新已经 COMMIT 成功，但对应数据页还停留在内存中就断电了。
重启后，InnoDB 可以根据 Redo Log 把这次更新重新应用到数据页上，让数据库恢复到“这次事务已经提交成功”的状态。
从原理上最该抓住什么
1. Redo Log 服务的是持久性，不是回滚
它最核心的职责是：
- 已提交修改的重做
不是：
- 未提交修改的撤销
后者更偏向 Undo Log。
2. Redo Log 是存储引擎内部恢复能力的一部分
它主要服务的是 InnoDB 自己如何恢复页，而不是数据库如何把变更对外广播出去。
这也是它和 Binlog 的根本分工差异。
3. Redo Log 和 WAL 思想相近，但术语体系不同
如果从思想上看：
- PostgreSQL 的 WAL
- MySQL InnoDB 的 Redo Log
都在服务“先写恢复依据，再慢慢写数据页”的恢复思路。
但它们属于不同产品语境，不应该机械地当成同一个组件名。