用 SQLite 当生产数据库：WAL 模式、并发上限与备份策略的完整配置

它比你想的能扛，也比你想的更容易被用错

很多人对 SQLite 的印象还停留在「手机 App 里的本地缓存」。实际上，它每天在数以十亿计的设备上承担着真实业务：大部分网站的会话数据、大量桌面软件的项目文件、不少中小型 SaaS 的主库，底层都是它。单个文件、零运维、事务完整，这些特性在小规模场景下比任何服务型数据库都省事。

但「能当生产库」和「直接当生产库用」是两件事。默认配置下的 SQLite 有明确的并发上限，而它的备份方式和 MySQL 完全不同——直接 cp 一个正在写入的库文件，可能得到一个损坏的副本。本文给出一份可以直接落地的配置，并列出四个真实踩过的坑。

1. 先判断你的负载在不在射程内

SQLite 的并发模型很简单：任意时刻只允许一个写者，读者可以有多个。这不是配置问题，是文件锁的物理限制，改不了。所以判断标准不是「访问量大不大」，而是「写操作密不密」。

适合：读多写少，写入可以串行化，单机部署，日写入量在几十万行以内
适合：边缘节点、内部工具、单租户应用、需要随应用一起打包分发的场景
不适合：持续高频写入（如每秒数百次 INSERT），多台机器同时写同一个库
不适合：库文件放在 NFS、SMB 等网络文件系统上——WAL 依赖共享内存，跨网络会直接失效

一个粗略的经验值：写事务每秒个位数到几十次，SQLite 完全无压力；一旦写请求开始排队，P99 延迟会以肉眼可见的方式塌陷，因为每个写者都在等同一把锁。

2. 四个 PRAGMA，决定它稳不稳

SQLite 的默认值偏向「兼容与安全」，不是偏向「生产吞吐」。下面四条是必设项，前三条建议写进连接初始化，第四条按库设置一次即可。

PRAGMA journal_mode = WAL;      -- 持久化设置，写一次即可
PRAGMA synchronous = NORMAL;    -- WAL 下的推荐值
PRAGMA busy_timeout = 5000;     -- 连接级，单位毫秒
PRAGMA foreign_keys = ON;       -- 连接级，默认关闭，必须手动开

journal_mode=WAL 是最关键的一条。回滚日志模式下，写操作会阻塞读；WAL 模式下读写互不阻塞，只有写与写之间互斥。这一条通常能带来数量级的并发改善。

synchronous=NORMAL 在 WAL 模式下是安全的：断电最多丢失最近若干个已提交事务，但不会损坏数据库。如果设成 FULL，每次提交都要 fsync，写入吞吐会掉一个档次；设成 OFF 则是拿完整性换速度，不建议。

busy_timeout 解决的是「锁等待直接报错」的问题。默认值是 0，意味着一旦遇到锁就立刻返回 SQLITE_BUSY。设成 5000 后，连接会自己等最多五秒，绝大多数瞬时竞争都能被消化掉。这一条不设，线上会频繁出现莫名其妙的写失败。

3. 写事务要短，批量写要包起来

WAL 解决了读写互斥，但写者之间仍然串行。所以真正的优化方向只有一个：让每次持锁的时间尽可能短。两条原则。

第一，不要在事务里做网络请求或文件 IO。一个事务里夹了一次 HTTP 调用，锁就被占了几百毫秒，后面所有写者一起排队。正确做法是先在外面把数据准备好，再开事务写入。

第二，批量插入必须显式包在一个事务里。SQLite 默认每条语句自动提交，一千条 INSERT 就是一千次 fsync。包进一个事务后，通常能快两个数量级。

BEGIN IMMEDIATE;
-- 一批 INSERT / UPDATE
COMMIT;

注意用 BEGIN IMMEDIATE 而不是裸 BEGIN。裸 BEGIN 是延迟事务，先拿读锁、写的时候再升级，升级失败会直接返回 SQLITE_BUSY 且 busy_timeout 对它无效；IMMEDIATE 一开始就拿写锁，把等待交给 busy_timeout 处理，行为可预期得多。

4. 备份：不要 cp，用 backup 或 VACUUM INTO

这是最容易出事的一环。数据库正在写入时，磁盘上的 .db 文件处于中间状态，直接复制可能拿到一个页级不一致的文件，而且往往要等到恢复那天才发现。

正确做法有三种，按场景选。

方式	命令	适用场景	注意
在线备份	sqlite3 app.db “.backup ‘/backup/app.db'”	库在线、需要一致性快照	内部用 backup API，可安全并发
导出压缩库	sqlite3 app.db “VACUUM INTO ‘/backup/app.db'”	想要一个紧凑的副本	目标文件必须不存在
停写后复制	先 checkpoint，再 cp	能接受短暂停机	必须同时处理 -wal 与 -shm