SQLite完整性检查为ok，为什么副本仍可能少订单

原创

用户10088940

修改于 2026-11-15 10:40:26

120

只复制SQLite主文件，得到的库可能仍能查询、结构检查也通过，却缺少已经提交到WAL的较新记录。对需要找回最后一批订单的读者，关键是把结构可读和目标事务范围分开核验。

技王数据恢复在本文提出的验收口径是：先说明副本来自哪个状态，再核目标业务记录；不能用一个integrity_check结果替代订单时间范围。下面用实际完成的自建数据库对照，说明这两个结论为何能够同时成立。

实际对照：两个副本均为ok，记录却不同

测试使用本机Python sqlite3模块，SQLite版本3.54.0。新建健康测试库，启用WAL并关闭自动检查点；建表后写入id=1并提交，再执行一次TRUNCATE检查点。随后写入id=2并提交，保持源连接打开，不再向数据库写入。

在这个静止状态下，分别复制主文件，以及同时复制主文件、配套WAL和SHM到两个独立测试目录。查询与检查只对测试副本执行。实际输出为：

main_only [(1,)] ok
matched_group [(1,), (2,)] ok

第一份副本没有id=2，但它并没有因此变成结构损坏的数据库。这就是检查点状态与事务范围之间的差异。本测试没有坏道、断电、加密或客户资料，不能据此推导故障盘能取得多少记录。

以下为复核脚本，只创建临时测试文件；不要改成对现有业务数据库或唯一故障原件执行。

import sqlite3, shutil, tempfile
from pathlib import Path
with tempfile.TemporaryDirectory() as tmp:
    root = Path(tmp)
    source = root / 'source.db'
    conn = sqlite3.connect(source)
    conn.execute('PRAGMA journal_mode=WAL')
    conn.execute('PRAGMA wal_autocheckpoint=0')
    conn.execute('CREATE TABLE orders(id INTEGER PRIMARY KEY)')
    conn.execute('INSERT INTO orders VALUES(1)')
    conn.commit()
    conn.execute('PRAGMA wal_checkpoint(TRUNCATE)')
    conn.execute('INSERT INTO orders VALUES(2)')
    conn.commit()
    for label, suffixes in [('main_only', ['']), ('matched_group', ['', '-wal', '-shm'])]:
        folder = root / label
        folder.mkdir()
        for suffix in suffixes:
            shutil.copyfile(str(source) + suffix, str(folder / 'sample.db') + suffix)
        with sqlite3.connect(folder / 'sample.db') as copy:
            rows = copy.execute('SELECT id FROM orders ORDER BY id').fetchall()
            check = copy.execute('PRAGMA integrity_check').fetchone()[0]
            print(label, rows, check)
    conn.close()

为什么不能只验文件能否打开

WAL是可选模式，不适用于每一个SQLite文件。官方说明把提交与检查点区分开：已提交变化可以仍在WAL中，检查点再把相应页面写回主文件。SHM用于索引协作，不是配套WAL的替代品。

上面的文件级复制只用于没有其他读写者的静止自建样本，不是在线备份方案。生产库持续变化时，逐文件先后复制不能保证一致快照，应依据应用环境选择官方在线备份接口或受控备份方式。

回到故障后的处理决定

若已有独立可用备份，可以在替代环境核它覆盖的业务范围，并另列备份之后的记录缺口。只有主文件时，应保留这个候选结果，同时保留已取得的相关文件及来源关系，不能从另一个时间点随便找同名WAL拼接。

介质反复断开或读错时，不要为了得到ok提示，在唯一原盘上反复启动应用、删除日志或触发检查点。数据库逻辑验证和介质读取条件是两个问题，应在保留原始输出的前提下安排分析副本。

验收可以明确到目标表、订单编号、确认时间及关联记录。未知缺口保留为待核；记录数量相同也需要核具体内容，而不能用本测试的两条样本替代真实业务一致性。

依据：SQLite WAL机制、数据库损坏原因与复制风险、官方在线备份接口。

2026年11月15日完成自建样本验证。本文含AI辅助整理，代码、输出与正文已核对；封面为机制示意，不是客户故障或恢复成果。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

数据恢复