SQLite 作为嵌入式数据库被大量桌面软件和移动 App 采用，但它对运行环境比较敏感，一旦宿主进程被强制杀死、存储设备掉电或文件系统出错，对应的 db 文件就可能发生损坏。损坏后的典型表现是执行查询时返回 SQLITE_CORRUPT 错误，或者命令行直接提示 database disk image is malformed。理解页结构和日志机制，是制定修复策略的前提。
SQLite 损坏的常见成因与底层原理
SQLite 将整个库切分成固定大小的页（page），默认一页 4096 字节，文件头之后的每一页都带有页头信息，其中包含用于校验的字段。当写入操作进行到一半被中断，某些页的数据没有完整落盘，页头中的大小字段或类型字段和实际负载对不上，再次打开时校验失败就会标记为损坏。此外，WAL 模式下的日志如果没有和主库正确合并，也会让读端看到不一致的状态。
从存储引擎角度看，SQLite 提供了 rollback journal 与 WAL 两种事务机制。在 rollback 模式下，修改前先把旧页复制到 journal 文件，提交后再删掉；如果删 journal 这一步丢了，下次打开会尝试回滚，但若 journal 本身残缺就可能修不好。WAL 模式则是把变更追加到 -wal 文件，checkpoint 时才写回主库，突然断电可能导致 wal 索引错乱。了解这些原理，有助于判断该用哪种恢复手段而不是盲目复制文件。
很多用户发现库打不开，第一反应是拷贝一份再试，其实这无法解决页内字节错误。更合理的第一步是用 PRAGMA integrity_check 让引擎扫描全部页并报告具体哪几页异常。如果只报零星页问题，往往可以通过导出再导入解决；若是文件头本身被覆写，则需要更底层的工具去捞游离页里的记录。
使用官方 sqlite3 命令行自带的修复能力
SQLite 发行包里的 sqlite3 程序自带几个非常实用的恢复指令。最传统的方式是先尝试用 .dump 把能读出的表和索引转成 SQL 文本，再新建一个库重新导入。即使中间遇到坏页导致 dump 中断，也可以加上 PRAGMA writable_schema=ON 跳过系统表错误，尽可能多导出用户数据。下面是一段在 shell 中操作的示例：
# 尝试导出结构和数据 sqlite3 broken.db .dump > dump.sql # 若中途报错，可忽略错误继续 sqlite3 broken.db "PRAGMA writable_schema=ON; .dump" > dump2.sql # 新建干净库并导入 sqlite3 new.db < dump.sql
从 SQLite 3.32 开始，官方在 sqlite3 中加入了 .recover 命令，它会绕过正常的事务校验，按页扫描文件并把还能解析的记录写进新库。相比 dump，recover 对碎片化损坏的容忍度更高，因为它直接读取自由页和溢出页。使用方式很简单，但要注意生成的是 SQL 脚本还是直接写库，可通过参数控制。
-- 在 sqlite3 交互界面中 .open broken.db .recover -- 或者一次性输出到文件 sqlite3 broken.db ".recover" > recovered.sql
需要提醒的是，VACUUM 命令会重写整个数据库文件，如果在已损坏的库上直接执行，可能把那些还没被覆盖的残留好页也清掉，反而降低恢复率。因此官方也建议先 recover 再考虑 vacuum。对于只是索引错乱的轻损，重建索引往往比整库导出更省事。
第三方图形化与解析类工具推荐
当命令行手段只能救回部分表，或者运维人员不熟悉 SQL 指令时，图形化工具有明显优势。SQLite Database Recovery、DB Browser for SQLite 这类软件可以直观列出可识别的表，并允许把记录导出为 CSV 或 Excel。它们底层通常实现了自己的页解析器，能够扫描未被文件头引用的游离页，把误删或事务残留的行也提取出来，这是官方工具做不到的。
| 工具类型 | 适用场景 | 优点 | 局限 |
|---|---|---|---|
| 官方 sqlite3 | 轻度页损坏 | 免费、无需安装依赖 | 重度损坏恢复率低 |
| DB Browser | 结构查看与简单导出 | 界面友好 | 遇到 malformed 易崩溃 |
| 专业恢复软件 | 文件头损坏、误删恢复 | 可捞游离页 | 多为收费 |
如果团队有开发能力，也可以用 SQLite 的 C API 自己写一个小程序：以只读方式打开文件，捕获 SQLITE_CORRUPT 后逐页读取，用 sqlite3_blob_open 直接访问页字节，按记录格式手工解析。这种方式虽然成本最高，但能针对业务表结构做定制，比如只恢复金额字段不为空的订单行。无论选哪种工具，都记得先对坏库做二进制副本，所有修复操作在副本上进行，避免二次破坏。
实际修复时建议遵循先易后难的顺序：先用 integrity_check 定位范围，再跑 .recover 导出，最后拿第三方工具补遗漏。养成定期备份和开启 WAL 定期 checkpoint 的习惯，能从源头减少这类突发损坏带来的损失。
SQLite数据库修复sqlite3_tool修改时间：2026-08-15 14:57:28