SQLite数据库在长期运行或遇到异常断电后，可能会出现文件内部页面校验失败的情况，此时执行常规查询会抛出database disk image is malformed错误。这种错误通常意味着数据库文件的部分页面已经损坏，无法通过普通的SQL语句读取数据。.recover命令是SQLite官方命令行工具中专门用于从损坏数据库提取可用数据的恢复机制。它不依赖事务日志，而是直接扫描底层B-tree页面结构，尽最大可能重建可读的记录集合。本文将从损坏场景的识别、.recover命令的具体用法以及自动化恢复流程三个层面展开，帮助开发人员在数据灾难发生时快速止损。
识别一致性问题的典型表现与常规工具的局限
SQLite数据库出现一致性错误时，最直观的表现就是应用层抛出SQLITE_CORRUPT或database disk image is malformed异常。这类错误可能在执行SELECT、INSERT甚至打开数据库连接时就出现。对于轻度损坏，数据库仍能打开，但某些特定表或索引的查询会失败；对于重度损坏，整个文件都可能无法加载。
常见的诊断手段是使用PRAGMA integrity_check命令。这个命令会遍历所有表和索引的B-tree结构，校验页面链接、记录格式与变长整型编码，如果发现不一致会逐条列出错误信息。例如执行PRAGMA integrity_check(10);可以限制返回的错误数量。然而，integrity_check只能报告问题，无法修复数据。同样，VACUUM命令虽然会重建数据库文件，但它要求源库本身能够被完整读取，一旦扫描到损坏页面，VACUUM大概率中途失败。另一个常用命令REINDEX只能重建索引，无法修复数据表页面。因此，当数据库文件真正出现页面级损坏时，必须依靠更底层的恢复工具，.recover命令就是为此设计的。
造成一致性损坏的原因很多：操作系统崩溃或断电导致写入未完成、磁盘坏道、文件系统错误、多进程同时以非WAL模式写入同一数据库文件、甚至SQLite版本升级过程中出现bug等。了解成因有助于事后预防，但当下最紧迫的是把数据抢救出来。
.recover命令的工作原理与基本用法
.recover是sqlite3交互式shell中的一个点命令，它并不执行SQL，而是指示CLI工具进入恢复模式。该命令会绕过常规的数据库打开流程，直接按页面粒度读取数据库文件，对每个B-tree页面进行独立解析。对于能够通过完整性检查的页面，其中的记录会被转换为INSERT语句；对于无法解析的页面，会尝试提取其中看起来完整的记录片段；完全失效的页面会被跳过。整个过程可以输出为一个SQL文本文件，之后将这个文件导入到一个全新的SQLite数据库中，就完成了数据重建。
基本用法有两种。第一种是直接启动sqlite3并指定损坏数据库和恢复命令：
# 将损坏数据库中的可恢复数据导出为recover.sql sqlite3 corrupt.db ".recover" > recover.sql
注意，.recover命令后面的输出重定向符号在shell中生效，sqlite3只是把生成的SQL语句打印到标准输出。第二种用法是先进入交互式shell，再手动执行.recover：
sqlite3 corrupt.db SQLite version 3.40.0 2022-11-16 12:10:08 Enter ".help" for usage hints. sqlite> .recover
执行后，终端会滚动输出大量的CREATE TABLE和INSERT语句。由于输出量可能很大，通常建议将输出重定向到文件。恢复脚本中除了建表和插入数据外，还会包含PRAGMA foreign_keys=OFF;等前置设置，以避免导入时外键约束干扰。恢复完成后，可以新建一个空数据库并导入该脚本：
sqlite3 recovered.db < recover.sql
需要注意的是，.recover并不保证数据百分百完整。对于损坏严重的页面，部分记录可能被跳过，或者只恢复部分字段。此外，自增主键的行号可能会重新分配，外键关联可能需要人工检查。如果数据库中某些表使用了WITHOUT ROWID结构，恢复成功率会相对降低，因为该类表的B-tree组织方式更复杂。
将.recover集成到自动化恢复流程与验证策略
在运维场景中，数据库损坏往往发生在生产环境的无人值守时段，手动执行恢复既不现实也不安全。可以通过编写脚本自动检测数据库损坏并在必要时调用sqlite3 CLI进行恢复。下面是一个Python示例，它先使用sqlite3模块尝试打开数据库并执行快速检查，如果检测到损坏，则调用系统的sqlite3命令进行恢复：
import sqlite3
import subprocess
import shutil
import os
DB_PATH = "app.db"
RECOVER_SCRIPT = "recover.sql"
NEW_DB_PATH = "app_recovered.db"
def check_corruption(db_path):
try:
conn = sqlite3.connect(db_path)
cur = conn.cursor()
cur.execute("PRAGMA quick_check;")
result = cur.fetchone()[0]
conn.close()
return result != "ok"
except sqlite3.DatabaseError:
return True
def recover_database(db_path, script_path):
with open(script_path, "w", encoding="utf-8") as f:
subprocess.run(
["sqlite3", db_path, ".recover"],
stdout=f,
stderr=subprocess.PIPE,
check=True
)
new_db = sqlite3.connect(NEW_DB_PATH)
with open(script_path, "r", encoding="utf-8") as f:
new_db.executescript(f.read())
new_db.close()
if check_corruption(DB_PATH):
print("检测到数据库损坏，开始执行.recover恢复...")
recover_database(DB_PATH, RECOVER_SCRIPT)
print(f"恢复完成，新数据库路径：{NEW_DB_PATH}")
else:
print("数据库状态正常，无需恢复。")
上述脚本先通过PRAGMA quick_check进行快速校验，该命令比integrity_check速度更快，适合常规健康检查。一旦发现异常，就调用操作系统中的sqlite3可执行文件，将.recover输出重定向到recover.sql，然后将该脚本导入到新的数据库文件。恢复完成后，建议再对新数据库执行一次完整的PRAGMA integrity_check，并对比原数据库中关键表的行数，评估数据丢失范围。在正式切换生产流量前，应备份原始损坏文件，以便后续进一步分析或尝试其他恢复手段。
除了被动恢复，预防措施同样重要。启用WAL模式可以显著减少数据库文件损坏的概率；定期执行PRAGMA wal_checkpoint(PASSIVE);将WAL内容合并回主数据库；将数据库文件存放在具备写时复制或快照能力的文件系统上；避免多个进程以非WAL模式同时打开写入。这些手段配合.recover命令，可以构建一套从预防到恢复的完整数据可靠性方案。
SQLite数据库.recover命令一致性修复修改时间：2026-08-25 10:09:45