SQLite数据库断电后回退至前一天状态，如何避免及排查原因？

成因分析 #

• DELETE日志模式的机制限制：当journal_mode设为DELETE时，SQLite会在事务启动时生成回滚日志文件（*.db-journal）。事务提交成功后，日志文件会被删除；若断电发生在事务提交过程中或未提交时，重启后SQLite检测到残留的回滚日志，会自动执行回滚操作，将数据库恢复到该事务启动前的状态。如果当日所有操作都在未提交的事务中，就会出现回退至前一天的情况——前一天的最后一个事务已正常提交并清理了日志。
• 事务粒度不合理：若POS系统将当日所有录入操作放在单个大事务中，或采用延迟提交策略，一旦断电，所有未提交的当日修改都会被回滚。
• 自增字段的关联性：SQLite的自增字段依赖sqlite_sequence表存储当前序列值，该表的更新属于事务的一部分。事务回滚时，sqlite_sequence的修改也会被撤销，导致自增字段值回退。

预防方法 #

• 切换为WAL日志模式：WAL（Write-Ahead Logging）是更可靠的写入模式，修改会先写入WAL文件，提交后再异步合并到主数据库。断电后仅丢失未提交的操作，已提交的数据不会受影响。启动程序时执行PRAGMA journal_mode=WAL;即可切换，该设置会持久化保存到数据库中。
• 缩小事务粒度：每完成一笔POS操作（如订单录入、收款确认）就立即提交事务，避免批量操作堆积在单个未提交事务中。例如每处理完一笔交易就执行COMMIT;，这样断电后最多丢失最后一笔未完成的操作。
• 配置同步级别：将synchronous参数设为FULL（默认值）或NORMAL，强制SQLite在事务提交时将日志/WAL文件刷新到磁盘，确保已提交数据写入物理存储。执行命令：PRAGMA synchronous=FULL;
• 定期备份与完整性检查：每日闭店后自动备份数据库文件；程序启动时执行PRAGMA integrity_check;，及时发现并处理数据库损坏问题。
• 排查事务泄漏：检查程序逻辑，避免出现事务开启后因异常分支未执行COMMIT或ROLLBACK导致的长时间未提交事务，这类情况会引发大量数据在断电时丢失。

内容的提问来源于stack exchange，提问作者Deivis Átila