SQLite数据库文件损坏通常不是无缘无故发生的。绝大多数情况下，问题出在写入过程中被意外打断、多个进程争抢同一个文件、或者存储介质本身不稳定。SQLite为了兼顾轻量和事务一致性，把大量一致性保障工作交给日志文件和操作系统文件锁完成，一旦这些外部条件不满足，主数据库文件就可能出现页级损坏。
一、写入中断如何破坏数据库文件
SQLite的原子提交机制依赖日志文件。在默认的回滚日志模式下，修改数据前会先把原始页写入-journal文件，然后再修改主数据库文件。如果写入过程中突然断电，或进程被强制终止，日志文件可能只写了一半，主数据库的页写入也可能没有完成。当下一次打开数据库时，SQLite会根据日志文件尝试回滚或恢复，但若日志本身已经损坏，恢复过程就会失败，数据库文件头或页结构就出现不一致。
WAL模式改善了这种状况，它把新数据先写入-wal文件，再通过检查点合并回主库。WAL模式在多数情况下能降低断电损坏的概率，因为它只在检查点阶段直接写主库文件。但如果检查点过程中系统崩溃，主库文件和WAL文件之间的关系可能会变得不完整。因此，开启WAL模式并不等于完全免疫损坏，它只是把风险窗口缩小到了检查点阶段。
可以在打开数据库后执行下面的语句来调整日志模式，并提高同步级别：
PRAGMA journal_mode=WAL; PRAGMA synchronous=FULL; PRAGMA wal_autocheckpoint=1000;
synchronous=FULL会让SQLite在事务提交时等待数据真正写入磁盘，虽然性能会有所下降，但能显著减少断电导致损坏的几率。对于不频繁写入的小型应用来说，这是一个值得开启的选项。
二、多进程并发与文件锁问题
SQLite支持多个进程同时读取同一个数据库文件，但写入操作必须获得独占锁。这个锁依赖底层文件系统的锁机制来协调。在本地文件系统上，SQLite的锁行为是可靠的，但如果数据库文件被放在NFS、SMB等网络文件系统上，文件锁可能无法正确实现，甚至被完全忽略。多个进程同时写入时，就可能破坏页结构。
除了文件系统的影响，应用层没有合理处理SQLITE_BUSY错误也是一个常见隐患。当一个进程持有写锁时，另一个进程尝试写入会立刻返回SQLITE_BUSY。如果代码不做重试或超时等待，只是简单报错退出，数据库通常不会损坏，但如果在持有锁期间进程被强杀，日志文件可能残留，恢复过程又与新写入冲突，就会增加损坏概率。
可以通过设置忙等待超时，让SQLite在锁冲突时自动等待一段时间：
PRAGMA busy_timeout=5000; PRAGMA locking_mode=NORMAL;
对于多进程写入场景，建议采用WAL模式并合理设置busy_timeout，这样多个进程可以同时读取，写入时也会等待而不是立即失败。真正需要高并发写入的场景，则应该考虑使用客户端服务器架构的数据库，而不是SQLite。
三、磁盘故障、网络存储与不当备份
磁盘坏道、SSD写放大、操作系统崩溃后的文件系统错误，都会直接导致SQLite数据库文件损坏。如果数据库文件所在的磁盘出现物理坏道，SQLite无法检测到数据读回不一致，直到某次查询或写入报错。此时损坏可能已经扩散到多个页，修复难度更大。
把数据库放在网络文件系统、移动硬盘或U盘上也是一个高风险的部署方式。这些介质在写入时往往有不稳定的延迟，某些网络文件系统还会缓存写入结果但不真正落盘。SQLite在事务提交时依赖fsync保证数据持久化，如果底层文件系统谎报写入成功，数据库文件就可能出现部分页更新而日志未同步的情况。
备份方式错误同样会造成损坏。直接复制正在写入的数据库文件，复制出来的备份可能处于不一致状态。正确的做法是使用SQLite自带的在线备份命令或VACUUM INTO：
VACUUM INTO 'D:\backup\app_backup.db';
这条命令会在保证事务一致性的前提下生成一个完整的新数据库文件。也可以使用SQLite命令行工具执行.backup，它内部调用的就是在线备份API，不会读到中间状态。
四、预防措施与损坏后的排查
预防SQLite数据库文件损坏，需要在架构设计阶段就避开高风险存储介质，尽量使用本地磁盘。部署环境稳定后，定期执行完整性检查是一个好习惯。可以在应用启动时执行PRAGMA integrity_check，如果返回的结果不是ok，就应该立即告警并切换到只读模式，避免进一步写入扩大损坏范围。
PRAGMA integrity_check; PRAGMA quick_check;
integrity_check会扫描整个数据库的页结构和索引一致性，耗时取决于数据库大小。对于生产环境，可以选择空闲时段运行，或者使用quick_check进行快速检查。两者都是只读操作，不会修改数据。
如果数据库已经损坏，可以尝试用命令行工具导出所有数据：
.mode insert .output dump.sql .dump .output stdout
将导出得到的SQL脚本重新导入到一个新的数据库文件中，往往能恢复大部分数据。但如果损坏发生在系统表或索引页，.dump可能也会中途失败。此时需要根据integrity_check的报错定位具体页，再考虑使用专业数据恢复工具。无论采取什么修复手段，保持备份永远是最后的防线，也是成本最低的保险。
SQLite数据库文件损坏SQLite数据库损坏修改时间：2026-09-24 14:09:57