- 据我所知，WAL 是一个仅追加文件，对 DB 的所有操作都会在对数据实际执行操作之前写入其中。
- 还有一个“检查点”的概念，即数据库实际将数据从内存写入磁盘，并在 WAL 末尾附加一个特殊的检查点条目。
- 现在，如果数据库在任何时候崩溃，它可以从最新的检查点条目开始读取 WAL 并重做所有后续操作。
- 但是数据库如何确保检查点 WAL 条目和数据实际刷新到磁盘以事务方式进行？
- 如果数据已刷新但数据库在 WAL 中创建检查点条目之前崩溃了，该怎么办？
- 相反，如果首先修改了 WAL，那么如果在检查点条目之后但在实际刷新数据之前 DB 崩溃，会发生什么情况。
例如，考虑以下情况：
- 我们有一张虚拟表
Person(name, age, salary)。 - 它有一个条目
John, 25, 100。 - 在时间T1，一个新的交易到达
UPDATE Person SET salary += 100 WHERE name='John'。 - 假设在 T1 之前，所有数据都已被刷新并且检查点条目已附加到 WAL。
- 现在，在此事务之后，数据库将首先在日志中附加精确的事务语句
UPDATE Person SET salary += 100 WHERE name='John'。 - 现在数据变成了
John, 25, 200。 - 然后过了一段时间，假设数据库决定在时间 T2 将数据刷新到磁盘。
- 然后在时间 T3（紧接着 T2）时，DB 尝试将检查点条目写入 WAL。
- 然而，航班尚未完成，T2和T3之间就发生了电源故障。
- 现在，当数据库重新启动并尝试恢复时，它会注意到最新检查点之后有一个事务，并将尝试执行该事务：
UPDATE Person SET salary += 100 WHERE name='John' - 但由于该交易在崩溃之前已经执行，这次工资将取值为 300，尽管它应该是 200。
数据库如何在恢复期间防止这些冗余更新？