文章目录
-
- [一、SQLite 持久化核心：主数据库文件](#一、SQLite 持久化核心：主数据库文件)
-
- [1.1 核心作用](#1.1 核心作用)
- [1.2 基础特性](#1.2 基础特性)
- 二、事务安全保障：回滚日志文件（journal）
-
- [2.1 产生场景](#2.1 产生场景)
- [2.2 核心作用](#2.2 核心作用)
- [2.3 常见误区](#2.3 常见误区)
- [三、高性能读写必备：WAL 模式辅助文件](#三、高性能读写必备：WAL 模式辅助文件)
-
- [3.1 WAL 文件（预写日志）](#3.1 WAL 文件（预写日志）)
- [3.2 SHM 共享内存文件](#3.2 SHM 共享内存文件)
- [3.3 核心价值](#3.3 核心价值)
- 四、高危禁忌：辅助文件绝对不能随意删除
-
- [4.1 随意删除的后果](#4.1 随意删除的后果)
- [4.2 正确操作时机](#4.2 正确操作时机)
- [五、极易踩坑：SQLite 目录权限问题](#五、极易踩坑：SQLite 目录权限问题)
-
- [5.1 原理说明](#5.1 原理说明)
- [5.2 开发规范](#5.2 开发规范)
- 六、关键生产规范：数据库一致性备份
-
- [6.1 直接复制文件的问题](#6.1 直接复制文件的问题)
- [6.2 生产级正确备份方案](#6.2 生产级正确备份方案)
- 七、全文总结与开发规范汇总
标签：SQLite、数据库原理、文件机制、数据备份、sqlite3、开发踩坑
前言
绝大多数开发者对 SQLite 的认知只停留在「单文件数据库」，认为项目中只要管好 .db 这一个文件就足够了。但在实际运行、事务写入、程序长期运行过程中，我们经常会看到目录中多出 .db-journal、.db-wal、.db-shm 等陌生文件。
很多人误以为这些是垃圾缓存文件，直接手动删除、移动、复制主库文件，最终导致数据损坏、事务丢失、数据库快照不完整、备份数据错乱等严重问题。
事实上，SQLite 看似是单文件数据库，运行时依赖主文件+辅助日志文件共同保障事务安全与读写性能。本文将完整拆解 SQLite 所有后缀文件的作用、产生场景、删除禁忌、目录权限要求与数据库一致性备份规范，彻底解决文件操作导致的各类数据库异常。
一、SQLite 持久化核心：主数据库文件
*.db 是 SQLite 的核心主库文件，也是我们常规认知里的数据库本体。
1.1 核心作用
主数据库文件永久保存数据库的全部核心数据，包含：数据表结构、字段定义、索引、触发器、视图、用户业务数据、数据库元数据等所有持久化信息。
无论程序重启、设备重启，只要该文件完好，数据库数据就不会丢失。
plain
app.db1.2 基础特性
- 唯一永久持久化文件，是数据库的真实载体；
- 文件大小随数据量动态增长；
- 单独的 db 文件可以完成数据库恢复、迁移、部署；
- 日常备份、迁移的核心目标文件。
但需要重点注意：数据库运行中，仅靠 db 文件无法保证数据一致性，事务运行期间必须依赖辅助日志文件协同工作。
二、事务安全保障：回滚日志文件（journal）
在默认事务模式下，SQLite 会自动生成 .db-journal 回滚日志文件，它是 SQLite 保障事务原子性的核心文件。
plain
app.db-journal2.1 产生场景
当数据库执行新增、修改、删除等写入事务时，SQLite 不会直接覆盖原数据，而是先将原始数据备份写入 journal 日志。
2.2 核心作用
- 事务失败回滚：如果程序崩溃、断电、代码异常导致事务中断，SQLite 依靠 journal 文件恢复原始数据，避免数据错乱、损坏；
- 保障原子性：确保一条SQL事务要么全部成功，要么全部回滚，不会出现半写数据；
- 事务正常提交完毕后，journal 文件会自动清空、删除。
2.3 常见误区
很多开发者看到该文件存在就手动删除，运行中删除 journal 文件会直接导致事务损坏、数据丢失、数据库报错。
三、高性能读写必备：WAL 模式辅助文件
当 SQLite 开启 WAL（预写日志）模式 后，数据库会抛弃传统 journal 日志，生成两套全新的辅助文件：.db-wal 和 .db-shm，也是现代 SQLite 项目主流运行模式。
plain
app.db-wal
app.db-shm3.1 WAL 文件（预写日志）
常规模式是「先改主文件」，WAL 模式是「先写日志、后合并主文件」。
- 所有新增、修改、删除操作优先写入 wal 日志；
- 读操作不受写操作阻塞，大幅提升并发读写性能；
- 数据库空闲或触发检查点时，将 wal 数据合并进主 db 文件。
3.2 SHM 共享内存文件
shm 是 WAL 模式的共享内存索引文件，用于多连接、多进程之间共享数据库读写状态、锁信息，保证并发读写安全。
3.3 核心价值
开启 WAL 模式后，SQLite 从「串行写」升级为「读可并行、写不阻塞读」，完美适配读多写少、高频查询的业务场景，是工程化项目的标准优化方案。
四、高危禁忌：辅助文件绝对不能随意删除
无论是 journal、wal、shm 文件，都属于数据库运行的核心依赖文件，而非垃圾文件。
开发、运维、部署过程中必须遵守核心规范：
数据库连接未完全关闭、程序未停止时，禁止删除、移动、重命名任何辅助文件。
4.1 随意删除的后果
- 正在运行的事务丢失，数据写入不完整；
- 数据库文件锁异常，后续无法正常读写；
- 主库与日志数据不一致，导致数据库损坏；
- 程序闪退、报错、数据错乱。
4.2 正确操作时机
所有文件复制、备份、移动、清理操作，必须满足两个前提：
- 业务程序完全停止；
- 所有数据库连接全部正常关闭。
连接彻底释放后，辅助文件会自动回收、清空，此时操作数据库文件绝对安全。
五、极易踩坑：SQLite 目录权限问题
绝大多数开发者只关注「db 文件是否可写」，却忽略了 SQLite 的权限特性，这是线上程序报错的高频原因。
SQLite 不仅需要数据库文件的写权限，还需要数据库所在文件夹的写权限。
5.1 原理说明
SQLite 运行过程中，会动态在同级目录创建 journal、wal、shm 临时日志文件，运行结束后再销毁或合并。如果目录没有写入权限，即便 db 文件本身可写，也会出现：
- 事务无法提交；
- 无法创建日志文件；
- 写入报错、数据保存失败；
- 数据库只读异常。
5.2 开发规范
部署项目、配置服务器权限、桌面软件打包时，必须保证数据库所在目录拥有读写权限，这是 SQLite 稳定运行的基础前提。
六、关键生产规范：数据库一致性备份
很多新手备份 SQLite 的方式非常粗暴：程序运行中、数据写入过程中，直接复制 .db 文件，这种方式无法得到完整一致的数据库快照。
6.1 直接复制文件的问题
数据库写入期间，大量数据暂存在 wal、journal 日志中，并未完全合并到主 db 文件。此时复制主文件，会导致：
- 备份文件数据不完整、缺失最新写入数据；
- 事务半截数据，备份快照错乱；
- 恢复备份后数据不一致、业务异常。
6.2 生产级正确备份方案
官方推荐、工程统一标准：优先使用 SQLite 内置备份机制，而非直接拷贝文件。
SQLite 备份接口会自动触发检查点、同步日志、合并数据、锁定快照，输出完整、一致、无损的纯净数据库备份文件，是唯一安全的生产备份方案。
如果必须手动拷贝文件，务必先停止业务、关闭所有连接，等待辅助文件自动回收后再操作。
七、全文总结与开发规范汇总
1、主数据库文件（.db） ：SQLite 永久持久化载体，保存所有业务数据与结构。
2、journal 回滚日志：默认事务模式的回滚保障，保证事务原子性，异常可恢复。
3、wal / shm 日志文件：WAL高性能模式核心文件，提升并发读写能力，是主流优化方案。
4、禁止动态删除辅助文件：运行中删除日志会导致数据库损坏、数据丢失，必须完全关闭连接后再操作。
5、目录权限大于文件权限：必须保证数据库所在目录可写，否则无法生成临时日志，写入报错。
6、拒绝暴力拷贝备份：运行中直接复制db文件无法保证一致性，生产环境优先使用官方备份机制。
看似简单的单文件 SQLite，底层依靠完整的日志机制保障数据安全与性能。掌握文件运行原理、权限要求、备份规范，是避免生产事故、写出稳健 SQLite 业务代码的核心关键。