SQLite 在单机上位机中的可靠使用：模式、备份与防损坏

SQLite 适合什么场景

单台设备、数据量不大（几万～几百万行）、不需要多机同时写，SQLite 是零运维的理想选择——一个文件就是整个库，部署简单。但如果是多设备高并发写入的服务器场景，应选时序数据库。

日志模式怎么选

• DELETE（回滚日志）：每次写直接落盘，行为直观，断电一致性好
• WAL（预写日志）：读写并发更好、写入更快，但会额外产生 -wal、-shm 文件

工程建议：追求稳妥、写入不频繁用 DELETE；追求写入性能用 WAL，但必须理解 wal 文件要和主库一起备份，且备份时要正确 checkpoint。本网站后台就曾因 WAL 与覆盖上传问题踩过坑。

高频写入要用事务

逐条 insert 会让每条都触发一次磁盘刷盘，非常慢。应该把一个采集周期的多条数据放进一个事务批量提交：

BEGIN;
INSERT INTO log VALUES (...),(...),(...);
COMMIT;

批量提交能让写入性能提升数量级，这是 SQLite 高频落库最关键的优化。

防止数据库损坏

1. 不要在程序运行时直接覆盖数据库文件，要先停服务再替换（这是 malformed 损坏的常见原因）
2. 备份用安全方式：VACUUM INTO 'backup.db' 或用 sqlite3 的 .backup，而不是直接复制正在写的文件
3. 异常断电后，SQLite 会用日志自动恢复，不要手动删 wal 文件
4. 定期跑 PRAGMA integrity_check 验证完整性

实用 PRAGMA 建议

PRAGMA journal_mode=WAL;   -- 或 DELETE，按场景
PRAGMA synchronous=NORMAL; -- 性能与安全的平衡
PRAGMA foreign_keys=ON;

数据滚动清理

单机存储有限，按时间保留（如只留近 90 天明细），定时删除旧数据并定期 VACUUM 回收空间，避免磁盘写满导致写入失败。

何时该升级

当出现：多进程/多机同时写、写入持续每秒上千、需要远程多客户端查询，就说明该从 SQLite 迁移到 TDengine/TimescaleDB 了。单机用 SQLite、服务器用时序库，是清晰的分层策略。