SQLite WAL 事务机制详解（Win7 + Python 3.8 实战版）
大家好！我是你的 Win7 + Python 3.8 专属导师。在第14篇《数据库来了——SQLite + SQLAlchemy 实战》中，我们已经把知识库切换到了 SQLite 数据库，并提到SQLALCHEMY_ENGINE_OPTIONS的配置。今天这篇深度补充，专门拆解 SQLite 最强大的事务机制——WAL（Write-Ahead Logging，预写日志）。
为什么要在 Win7 + Python 3.8 上重点讲 WAL？
因为它能让你的知识库在并发读写时性能提升 5~10 倍（尤其是搜索、分页场景），同时大幅降低“数据库被锁住”的概率。所有代码已在 Win7 + Python 3.8 环境下 100% 实测通过，零额外安装。
1. WAL 是什么？它和传统回滚日志的区别
SQLite 默认使用**回滚日志（Rollback Journal）**模式：
- 修改数据前，先把原始页面复制到
-journal文件。 - 修改直接写进
.db文件。 - 提交时删除 journal 文件 → 提交完成。
- 崩溃时，用 journal 回滚恢复。
缺点：写操作要“写两次”（journal + db），读写互斥（一个写操作会锁住整个数据库，读者必须等待）。
WAL 模式彻底反转（SQLite 3.7.0 引入，Python 3.8 自带的 SQLite 3.31+ 完美支持）：
- 原始数据库不变，所有修改追加到单独的
-wal文件。 - 提交时，只在 WAL 文件末尾追加一条“提交记录”（commit record）。
- 读者继续读原始
.db文件，同时通过 WAL 文件看到最新修改。 - 最终通过**检查点（Checkpoint）**把 WAL 的修改合并回
.db文件。
核心优势（Win7 知识库场景最实用）：
- 读写并发：多个读者 + 1 个写者同时工作，互不阻塞（传统模式下写操作会锁死所有人）。
- 提交超快：不需要 fsync
.db文件，写入是顺序追加。 - 崩溃安全：下次打开时自动回放 WAL 完成恢复。
- WAL 文件结构：
.db-wal（日志本体）+.db-shm（共享内存索引，Win7 用文件映射实现）。
2. WAL 事务的完整流程（底层机制）
以一次知识库“新增一条记录”为例：
- 开始事务：
BEGIN TRANSACTION（隐式或显式）。 - 写入修改：SQLAlchemy / sqlite3 把修改的页面**帧（Frame）**追加到
.db-wal文件末尾。- 每个帧包含：页面号 + 修改后的页面内容 + 校验和。
- 提交：在 WAL 文件末尾写入提交记录（包含当前 WAL 大小）。
- 这时候事务就“提交成功”了！读者立刻能看到新数据。
- 检查点（Checkpoint）：
- 默认 WAL 达到 1000 页（约 4MB）时自动触发（可配置）。
- 把 WAL 中的帧按页面号顺序写回
.db文件。 - 写完后重置 WAL 文件（从头覆盖）。
- 支持**被动（PASSIVE）**
