面试题答案
一键面试SQLite WAL模式下检查点（checkpoint）的工作原理
- WAL模式概述：在WAL（Write - Ahead Logging）模式下，SQLite并不直接将数据修改写入数据库文件，而是先将修改记录到一个单独的日志文件（WAL文件）中。每个事务会在WAL文件中追加一条记录，这种方式允许并发读写操作，因为读操作可以直接从数据库文件读取，而写操作只影响WAL文件。
- 检查点概念：检查点是一个将WAL文件中的修改合并回数据库文件的过程。随着事务不断进行，WAL文件会逐渐增大。检查点操作就是把WAL文件中已提交事务的修改应用到数据库文件，并截断WAL文件，释放空间。
- 工作流程：
- 扫描WAL文件：从WAL文件的头部开始扫描，识别已提交事务的记录。
- 应用修改：按照事务提交顺序，将WAL文件中的修改应用到数据库文件对应的页面上。这个过程可能涉及到更新页面数据、索引等结构。
- 截断WAL文件：在所有已提交事务的修改都应用到数据库文件后，截断WAL文件，保留未提交事务的部分，以准备下一轮事务操作。
对故障恢复机制的影响
- 提高恢复效率：由于检查点定期将已提交事务的修改合并回数据库文件，在发生故障时，只需要重放检查点之后的WAL日志记录，而不需要重放整个日志，大大缩短了恢复时间。
- 保证数据一致性：检查点确保数据库文件在一定时间间隔内与已提交事务的状态保持一致。即使系统崩溃，在恢复过程中，通过重放检查点之后的WAL日志，可以使数据库恢复到崩溃前已提交事务的状态，保证数据的一致性。
系统崩溃后利用WAL日志进行恢复
- 恢复流程：
- 定位检查点：数据库启动时，首先定位最近一次检查点的位置。这通常可以通过数据库文件头中的信息或者专门的元数据记录来确定。
- 重放日志：从检查点之后的WAL日志记录开始，按照顺序重放所有已提交事务的记录。在重放过程中，将WAL日志中的修改再次应用到数据库文件上，恢复数据库到崩溃前已提交事务的状态。
- 清理未提交事务：在重放完已提交事务的日志后，清理WAL文件中未提交事务的记录，因为这些事务没有完成，不能将其修改应用到数据库。
- 可能遇到的挑战及应对方法：
- WAL文件损坏：
- 挑战：如果WAL文件在系统崩溃时部分损坏，可能导致恢复过程中无法正确重放日志记录。
- 应对：SQLite通过在WAL文件中使用校验和（checksum）来检测文件损坏。在重放日志前，先验证每条记录的校验和，跳过损坏的记录，并在可能的情况下尽量恢复其他部分。同时，还可以通过备份机制，在检测到严重损坏时从备份中恢复。
- 并发事务冲突：
- 挑战：在恢复过程中，可能存在一些并发事务的残留状态，例如锁信息等，这可能导致重放日志时出现冲突。
- 应对：SQLite在恢复过程中会重新构建事务状态信息，包括锁状态等。通过按照事务提交顺序重放日志，并依据事务隔离级别等规则处理冲突，确保恢复后的数据库状态符合预期。例如，对于某些冲突，可以采取回滚未提交事务的方式来解决。
- 日志记录丢失：
- 挑战：在系统崩溃时，可能存在部分已提交事务的日志记录还未完全写入WAL文件，导致这些事务的修改无法恢复。
- 应对：SQLite采用预写式日志的方式，在事务提交前尽可能确保日志记录已经持久化。此外，通过设置合适的同步策略（如
PRAGMA synchronous），可以在一定程度上减少日志记录丢失的风险。同时，结合备份和恢复机制，在极端情况下可以从备份中恢复数据库，并结合后续的日志重放来尽量接近崩溃前的状态。
- WAL文件损坏：