网关SQLite的WAL越长越大，怎样查出一直不结束的报表读事务

WAL持续增长时，先找仍持有旧快照的读事务，再观察checkpoint是否推进。不要直接删除wal文件，也不要把文件仍很大等同于checkpoint完全没有工作；可复用容量与文件长度是两件事。

画出读事务与写提交时间线

一个报表连接执行SELECT以后，如果事务没有结束，它可能继续持有开始读取时的快照。写连接仍能追加提交，读者却让checkpoint不能越过它所需的边界。报表已经把结果取完，不代表应用自动结束显式BEGIN；游标、连接池归还和异常分支都值得检查。

建立受控WAL与双连接样例

实验先开启WAL并关闭自动checkpoint，在读连接保持事务时提交十批合成记录。PASSIVE返回的日志页数大于已回填页数，表明本轮没有全部推进。读事务回滚以后，再对这份临时库执行TRUNCATE；输出同时保留返回三元组和前后字节，避免只凭一个尺寸猜测。

checkpoint返回的三元组应按忙状态、WAL页数、已回填页数阅读，不要把第二项直接称为未写入磁盘的数据。PASSIVE可以只推进一部分；TRUNCATE则有收缩目标，两者请求不同。因此本文把读事务释放前后的推进状态与实际字节同时保留，比较时应对应到具体checkpoint模式。

说明不能直接删除WAL与共享盘限制

修复重点是缩短读事务：先取需要的数据并结束事务，再做格式化、压缩或网络发送。生产环境是否适合主动checkpoint，还要结合写入频率、磁盘、备份和SQLite版本评估；本例规模很小，不能由它推算大库暂停时间，更不能保证任何时刻都能把文件缩为零。

适用范围：只建临时小库，绝不删现有WAL；文件大小以实际运行记录，不承诺每次checkpoint即缩文件。

配套样本与复核入口

• run.py：独立运行程序，包含合成输入、操作和正反例断言。
• case.json：输入说明、预期任务与适用范围，便于保存和交接。
• observed.json：本次实际执行输出；临时路径、进程号和计时可能随运行变化。

下载后运行会在临时目录创建小库，并在退出前关闭两个连接。先看held_reader_checkpoint后两项是否有差距，再看释放读事务后的输出；wal_before是本次实际字节，不应直接照抄别人的尺寸。若环境得到不同页数，保留SQLite版本与三元组，先解释页数为何变化，再判断读事务是否真的阻止了推进。

Python3.8以上及标准库；使用Python自带SQLite。程序不读取现有网关数据库，全部样本写入内存或新建临时目录，执行完自动清理；没有任何模型API调用。

python -B run.py

阅读输出时，先按case.json中的任务逐项核对网关SQLite WAL长读事务，再与observed.json比较。非零退出表示依赖或断言需要处理，应保留实际错误。

一手依据1（长期读事务阻碍checkpoint推进；WAL仍只有一个写入者且不适用于跨主机网络文件系统。）；一手依据2（wal_checkpoint返回忙状态、WAL日志页数和已回填页数；PASSIVE尽可能推进而不等待，TRUNCATE在完成回填后尝试将WAL文件缩为零。）。

继续阅读：改一个渠道却让其他写入都报database is locked，怎样缩短SQLite写事务；删掉旧网关用量记录后db文件为何没变小，怎样估算VACUUM前的空间；New API 升级前备份了，怎样演练一次真正可用的恢复。