SQLite WAL卡死Codex：优化再次崩溃
来源：互联网 2026-07-29 19:13:13Codex桌面应用因SQLite的WAL日志膨胀至4MB（数据库仅300KB）且日志数据库达70MB（其中52%为TRACE日志），导致点击历史对话时假死。通过手动checkpoint合并WAL、清理日志、一键启动器以及每3小时的定时任务，实现了自动维护，从而恢复应用流畅，彻底解决假死问题。
TL;DR
上篇文章我们通过“预建缓存 + PowerShell 原生读取”把对话记录从6秒降到了88毫秒，效果相当不错。但两周后，Codex桌面应用突然彻底卡死——点击任何历史对话就假死，不是慢，是完全没反应。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
本次问题的根因有两个，且隐藏更深：
- SQLite WAL日志膨胀：
state_5.sqlite的WAL文件从0涨到4MB（数据库本身仅300KB），每次读取需扫描870页未合并日志； - 日志数据库失控：
logs_2.sqlite膨胀至70MB，其中52%为TRACE级别日志。
解决方案是一套组合拳：一键启动器（启动即清理）+ Windows定时任务（每3小时自动维护）+ 增强版rh。
又出问题了
上篇文章发布后，rh命令一直表现优秀——88毫秒秒出，毫无卡顿，我甚至几乎忘记了桌面应用侧边栏那个“加载中…”的提示。
直到某天，Codex桌面应用突然彻底卡死。注意，不是慢——点击任何历史对话就假死，任务管理器直接显示“无响应”。
有趣的是，终端中的rh仍可秒出。这说明数据并未损坏，问题出在应用本身。
排查：三个SQLite文件的秘密
Codex的数据目录~/.codex中藏着三个SQLite数据库：
state_5.sqlite 300KB ← 对话元数据（线程、标题、模型）
logs_2.sqlite 70MB ← 运行日志
goals_1.sqlite 24KB ← 目标任务
仅看大小似乎都正常，直到我注意到同名的.sqlite-wal文件：
state_5.sqlite 300KB ← 数据库本体
state_5.sqlite-wal 4.1MB ← WAL日志！！！
state_5.sqlite-shm 32KB
logs_2.sqlite 70MB
logs_2.sqlite-wal 4.2MB ← 又是4MB WAL
WAL文件比数据库本体大了13倍。这才是真正元凶。
什么是WAL，为何会膨胀至此？
SQLite默认使用WAL（Write-Ahead Log）模式。简单来说：写操作不直接修改数据库，而是先写入WAL文件；读操作需同时查询数据库+WAL，合并最新结果；当WAL积累到一定大小，才会触发checkpoint合并回主数据库。
正常情况下，该过程对用户透明。但Codex桌面应用运行期间持续高频写入（记录日志、更新状态），而checkpoint频率跟不上写入速度，导致WAL像滚雪球一样越来越大。
正常WAL：▏ 数KB，随时合并
Codex的WAL：████████████████ 4MB，870页待合并
每次切换对话，应用读取state_5.sqlite时，SQLite需在870页WAL中逐页查找最新数据。870次磁盘IO，每次数百毫秒——UI线程直接卡死。这是问题根源。
解决方案
1. 手动checkpoint：将WAL合并回数据库
import sqlite3
conn = sqlite3.connect("state_5.sqlite")
conn.execute("PRAGMA wal_checkpoint(TRUNCATE)")
conn.close()
效果立竿见影：
state_5.sqlite-wal: 4,140KB → 0KB
logs_2.sqlite-wal: 4,273KB → 0KB
但这只是临时措施。Codex继续运行，几小时后WAL又会涨回来。
2. 日志数据库大扫除
logs_2.sqlite为何70MB？查看日志级别分布便知：
TRACE: 17,578条 (52.1%) ← 全是HTTP连接、文件监控、SSE流的冗余日志
INFO: 7,508条
DEBUG: 7,328条
WARN: 1,302条
ERROR: 33条
超过一半为TRACE日志，每次HTTP请求、每个文件变动都记录一条。删除TRACE和DEBUG后：
logs_2.sqlite: 70MB → ~15MB
3. 一键启动器：从此无需手动操作
手动执行checkpoint太不智能。编写启动器codex_launcher.ps1，每次双击即可：
- 检查Codex是否已在运行
- 对三个数据库执行WAL checkpoint
- 日志超过30MB时自动清理TRACE/DEBUG
- 清理临时文件
- 启动Codex桌面应用
放在桌面作为快捷方式，从此启动即清爽。
4. Windows定时任务：无人值守维护
绕不开的问题：Codex运行时数据库被锁定，无法清理。因此设置Windows定时任务，每3小时自动运行一次——若Codex恰好关闭，则自动清理；若开启，则等待下一次。
schtasks /Create /TN "Codex DB Auto Cleanup" /SC DAILY /RI 180 /DU 24:00 /IT /F `
/TR "powershell -WindowStyle Hidden -File codex_cleanup.ps1"
5. 增强版rh：搜索 + 详情
原rh仅支持列表和查看详情。增强版新增关键词搜索：
rh # 列表（88ms）
rh 赛博朋克 # 搜索标题含"赛博朋克"的对话
rh 019e6a94 # 查看指定对话详情
rh --rebuild # 强制刷新缓存
此外，rh现可被cmd和PowerShell同时识别，已被复制到PATH目录。
完整文件清单
| 文件 | 用途 | 新增 |
|---|---|---|
build_cache.py | SQLite + JSONL → JSON缓存 | 原有 |
rh.ps1 | 列表 / 搜索 / 详情（PowerShell原生） | 增强 |
codex_cleanup.ps1 | WAL checkpoint + 日志清理 + VACUUM | 新增 |
codex_launcher.ps1 | 清理 → 启动Codex（一键） | 新增 |
codex_launcher.bat | bat包装器，双击即用 | 新增 |
教训
本次追查让我对SQLite WAL有了切身体会：
Codex的问题在于将大量TRACE日志和状态更新写入WAL，却不及时checkpoint。应用开发者应要么降低日志级别，要么定期主动执行checkpoint。
对用户而言，上篇解决的是"慢"，本篇解决的是"死"。两者配合才构成完整方案：
终端浏览（快）← rh → 88ms → 上篇
应用不卡（稳）← cleanup + launcher → 本篇
自动维护（省心）← 定时任务 → 本篇
若你也遇到"以为修好了结果又崩了"的情况，别急着怀疑之前方案——先检查SQLite的WAL文件和日志数据库，这个坑比Python冷启动藏得更深。