基于日志的恢复：先写日志原则与undo/redo操作

仅靠定期转储的备份文件，无法保障备份时刻到故障发生这段时间内已 提交事务的持久性——这段时间的操作还没进入下一次备份，一旦系统 崩溃就可能凭空丢失，这正是日志技术存在的意义。基于日志的恢复要求 “先写日志”：任何一次数据修改，必须先把这次修改的详细信息（事务ID、 数据对象、修改前旧值、修改后新值）写入日志文件，才能真正去修改 数据库本身——这个顺序不能颠倒，否则一旦在”改了数据但还没写日志” 的瞬间崩溃，恢复时就没有任何记录能还原这次修改。日志记录本身假设 存储在可靠的稳定存储器上、不会丢失，因此系统崩溃后可以完全依赖 日志把数据库恢复到崩溃前的最新一致状态，恢复过程围绕两个互为镜像 的操作展开：undo（撤销）把某个事务已做的修改全部还原成旧值，用于 处理”没有提交就崩溃”的事务；redo（重做）把某个事务的修改重新应用 成新值，用于处理”已经提交、但改动可能还没真正落盘”的事务——因为 数据库更新往往先停留在内存缓冲区、不会立即写入磁盘，即使事务已经 提交，它的修改结果也不一定已经物理写入数据库文件，所以恢复时必须 对所有已提交事务重做一遍，确保它们的结果真的落到磁盘上，而不能 想当然认为”提交了=已经写入磁盘了”。

结构图：

flowchart LR
    A[事务要修改数据] --> B[先写日志记录<br/>事务ID+旧值+新值]
    B --> C[再真正修改数据库]
    D[系统崩溃恢复] --> E{扫描日志判断事务状态}
    E -->|已提交但可能未落盘| F[redo: 重做修改<br/>确保结果真正写入磁盘]
    E -->|未提交就崩溃| G[undo: 撤销修改<br/>还原成旧值]