SQLite生产实践：从选型评估到调优部署的完整指南

2025年还在用SQLite做生产存储，很多人第一反应是"你们是不是没预算上正经数据库"。但我这几年在真实项目里反复用SQLite踩坑、调优、扛流量之后，必须说一句：SQLite在生产环境的适应能力，被严重低估了。它绝不是只能存本地配置的小玩具，很多看起来"应该上MySQL/PG"的场景，其实用SQLite反而是更合理的架构决策。这篇文章不打算复述官方文档，而是以我和团队实际维护过的生产系统为蓝本，把我评估选型、参数调优、问题排障、容器化部署、备份恢复整套经验一次性讲透。

1. 先泼盆冷水再给答案：SQLite不是"看不起的玩具库"

先聊聊我为什么会在一套正式业务系统里选择SQLite。那是一个边缘侧的本地调度服务，单机部署，资源预算非常有限，整个机器只有2核4G，还需要跑好几个业务进程。业务方最初坚持要上MySQL，理由是"生产环境怎么能用SQLite"。后来我把需求拆开看：最大并发连接数不超过10，90%的流量是读状态，写入基本是单线程的定时落库，数据总量一年撑死几十GB。这种负载之下，MySQL集群不仅浪费资源，还带来了主从同步、账号权限、连接池管理等一堆本不需要存在的运维成本。于是我们改用SQLite，上线后CPU和内存占用几乎可以忽略。

我举这个例子不是要说MySQL不行，而是提醒大家：生产环境选型的第一原则不是"别人都用什么"，而是"这个场景真正需要什么"。SQLite是嵌入式关系型数据库，它把整个数据库引擎作为库文件直接链进应用进程，不需要独立的数据库服务进程，不需要监听端口，不需要专门的DBA维护实例。这个特性决定了它在单机、低并发、数据量可控但逻辑关系复杂的场景里，起手就比客户端/服务端架构的数据库少了一大截开销。

作为选型负责人，我一般从四个维度判断SQLite能不能上生产：

有一点需要强调：选SQLite不能是"为了方便省事"的偷懒，而应当是经过负载评估后确认它恰好落在能力范围之内的决策。如果一个系统明确预测未来的写TPS会持续超过SQLite单文件的处理能力，或者需要多台应用服务器同时直连同一个库，那还是老老实实上专用数据库，不要硬扛。

2. 生产选型前，把这几个能力边界算清楚

我在评审技术方案时最不喜欢听到一句话："先用SQLite顶一下，不行再迁移。"数据库迁移从来不是低成本的事。所以必须在项目启动前对SQLite的能力边界做一次完整推演。以下这几个点，决定了它能不能在你的生产场景里站稳。

2.1 并发模型：SQLite实际上锁的是什么

SQLite传统的锁机制是整库级别的读写锁。未开启WAL模式时，读会阻塞写，写也会阻塞读，这种"一夫一妻"式的互斥基本适应不了真实业务。生产环境使用SQLite几乎必须打开WAL（Write-Ahead Logging）模式。WAL模式下，读事务和写事务可以在一定程度上并行：写操作只会追加到wal文件，读操作继续从原来的数据库文件读取快照，因此读不会阻塞写，写也不会阻塞读。

但是要注意，WAL并没有把SQLite变成多写并发数据库。写入仍然是全局串行化的，同一时刻只允许一个写事务提交。所以评估一个场景能不能用SQLite，核心不是看并发连接数，而是看"写入吞吐需求"和"写入冲突概率"。如果一个瞬间有几十个请求同时尝试写入，虽然WAL允许进程间的读并发，但写锁只有一个，后面的写请求如果超过busy_timeout还没有等到锁，就会直接返回SQLITE_BUSY。

我通常用一个非常粗的公式估算写入压力：单条写事务耗时约0.1到几毫秒（取决于数据量和磁盘），再留出50%的余量，推算出单库每秒大约能完成多少写事务。这个数字不需要很精确，因为决定吞吐上限的往往是磁盘fsync频率，而不是CPU。只要评估结果距离未来峰值流量还有3到5倍余量，SQLite基本就没问题。

2.2 事务与持久性：不是崩溃后一定丢数据

很多人对SQLite持久性的印象还停留在"PRAGMA synchronous=OFF，一断电就丢数据"。实际上SQLite的可靠性是可以按需配置的。默认的DELETE模式加synchronous=FULL，每提交一个事务都要把数据刷到磁盘，安全性相当高。在WAL模式下把synchronous调整为NORMAL，只保证在操作系统崩溃时可能丢失最近少量提交事务，但在应用崩溃或者断电场景下数据库文件本身不会损坏。反过来，如果误把synchronous设成OFF，那系统断电或者进程被kill -9的瞬间，确实可能丢数据甚至损坏库文件。所以不是SQLite不持久，而是你必须知道自己设置到了哪一档。

这部分在生产环境配置上有个我常用的组合：journal_mode=WAL，synchronous=NORMAL，busy_timeout=5000。这个组合兼顾并发性能与安全性，适合绝大多数单机生产服务。只有当写操作本身要求极其严苛的"不丢任何已提交事务"时，才会把synchronous升到FULL。注意，升级到FULL会让每次提交都等待落盘，写吞吐会明显下降，要在业务上判断能不能接受。

2.3 多进程还是单进程多连接

很多新手会混淆"SQLite支持多线程"和"SQLite支持多进程同时打开同一个库"。这两件事都支持，但使用条件不一样。SQLite本身是线程安全的，前提是编译参数开启了THREADSAFE，而且同一个连接不能同时被多个线程无保护地使用。大多数语言驱动会为每个线程单独创建连接，这没问题。真正需要警惕的是多个独立进程（比如多个Java服务实例）同时对同一个db文件做频繁写操作，这种情况下WAL虽然能撑住一定并发，但性能对比单进程访问会有明显劣化，因为文件锁的协调开销摆在那里。

生产选型时如果服务是多副本部署，每个副本都要读写同一份SQLite文件，这基本就宣告了方案不成立。SQLite的文件锁在网络文件系统上的表现不可控，多副本共享一个库文件是事故高发区。正确做法是：要么把SQLite绑定在唯一一个有状态节点上，要么改为每个副本本地各持一份库，通过业务层同步数据，要么干脆换用真正的网络数据库。

3. 我长期维护过的三类SQLite生产形态

理论讲完，说说我在真实环境里见到的、以及亲手维护过的几类SQLite生产用法。这些不是Demo级的"新建数据库、插入一条、查询一条"，而是承担真实业务压力的架构形态。

3.1 单机服务的元数据与调度状态存储

这是SQLite存在的最大价值区间之一。很多后台服务自身需要持久化一些结构数据：定时任务的执行状态、分布式锁的注册表、导入任务的批次进度、各个模块的配置项。过去这些数据要么塞进Redis（可丢了就麻烦），要么为了几个表专门搭一套MySQL。实际上如果只有一个副本，这些数据用SQLite存非常顺手。

我做过一个定时调度引擎，核心表就是任务定义表和任务执行记录表。调度器每隔几百毫秒检查一次是否有任务到期，触发任务时更新执行状态，任务完成后写入结果摘要。表面看写入频率不低，但因为所有操作并发度低，甚至在单连接下顺序完成，SQLite表现得非常稳定。对比以前用MySQL的方案，省掉了连接池和网络开销，服务启动时打开数据库文件就算"连上库"了，真正做到了开箱即用。

3.2 本地业务系统的核心关系库

还有一类场景是工业现场或门店级别的核心业务库。例如产线数据采集程序，必须将设备上报的数据持久化并按订单号、批次号做复杂聚合分析。这种环境通常只有一台工控机，带宽有限，网络不稳，不可能指望机房里的中心数据库随时可达。SQLite作为本地核心库完全够格：它支持标准的SQL语法，有事务，有索引，有视图，能跑复杂的JOIN和子查询，和那种只能KV读写的嵌入式存储不是一个级别。

我遇到的具体案例是一套设备数据记录系统，每秒钟从传感器采集几十个点，每五分钟批量写入一次，单次写入事务会包含几千行数据。这种"低频大批量"的写入模型SQLite处理得有滋有味。我们在WAL模式下批量插入几万行，单事务提交耗时通常在几十毫秒量级。查询侧则依赖合理的复合索引，终端上查一天的曲线数据基本点击即出。这里的关键优化是把高频采集先放内存队列，攒够一批再开启事务统一写入，千万不要一行一行自动提交。

3.3 高并发架构里的本地缓冲与降级存储

SQLite还能扮演一个很特殊的角色：核心数据库故障时的降级缓冲。之前我参与设计过一个对可用性要求很高的交易网关服务。网关本身无状态，可以多实例横向扩容，但后端的中心数据库如果抖动，会导致整个链路失败。我们最终的架构是在每个网关节点本地部署一个SQLite库，正常流量直接实时上报，同时把必要的交易上下文先异步写一份到本地SQLite作为审计和缓冲。一旦中心数据库不可用，网关自动切换为"本地落地"模式，把交易数据完整写到SQLite；等中心库恢复，后台任务再从SQLite里把数据有状态地补推到中心。这个设计让网关在依赖不可用时依然能继续接收请求，本地SQLite在整个降级流程中没有出现过一次数据损坏。

这个场景印证了一点：SQLite在嵌入式设备、边缘节点、中间层里面其实是"轻量高可靠"的选项，绝不是只能用在小工具里的临时存储。前提是架构师要清楚它的边界，把它放在单机、有状态、可容忍读多写少的舞台上。

4. 让SQLite扛住高吞吐的三个层面：参数、事务、连接

我见过太多项目上线前不调任何PRAGMA参数，遇到性能问题就怪SQLite不行。实际上大多数"SQLite太慢"的案例，都是因为默认配置根本不符合业务场景。下面这些参数和用法是我在压测和生产中反复用过、验证过有效的一套组合。

4.1 WAL模式下必调的PRAGMA组合

应用在打开数据库连接后，第一时间执行这几条PRAGMA：

sql复制PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;
PRAGMA busy_timeout=5000;
PRAGMA wal_autocheckpoint=1000;
PRAGMA cache_size=-64000;

逐个解释设置理由：

• journal_mode=WAL：读不阻塞写、写不阻塞读，这是并发场景的基础。
• synchronous=NORMAL：WAL模式下即使系统崩溃，也不会损坏数据库，最多丢失最近少量已提交事务，对绝大多数业务可接受，换来的是显著的写入速度提升。
• busy_timeout=5000：当写锁被其他连接持有时，SQLite默认会立刻返回SQLITE_BUSY，应用如果不重试就会报错。设成5000毫秒后，SQLite会在锁释放前自动等待，很多"莫名报数据库被锁"的问题其实加这一条就缓解了。
• wal_autocheckpoint=1000：WAL文件累积到约1000页（默认4KB一页就是4MB）时自动触发checkpoint，将WAL内容合并回主库文件。设得太小会导致频繁合并影响性能，设得太大容易让WAL文件膨胀，1000是一个比较稳妥的默认值。
• cache_size=-64000：单位是KB，负号表示按KB计算，也就是大约64MB的页缓存。这个值需要根据机器内存调整，但绝大多数服务给SQLite分64到128MB缓存都不过分，能明显加速读操作。

注意，代码里设置PRAGMA要捕获执行错误，因为journal_mode从DELETE切到WAL必须拿到独占锁，如果正好有别的事务在执行，可能切换失败。我一般在应用启动早期、还没有业务流量时先做一次完整初始化，确保成功进入WAL模式。

4.2 写入侧设计：小事务攒批，UPSERT一条语句搞定

SQLite单条写入再快也经不起几千次独立提交。每次独立提交就是一次文件同步，而fsync通常是写入链路上最贵的一环。生产环境里想让SQLite写得更快，核心思路就一句话：把多次写入合并到少量大事务里。批量插入时我用事务包裹：

python复制import sqlite3

conn = sqlite3.connect('app.db', timeout=5)
conn.execute('PRAGMA journal_mode=WAL;')
conn.execute('PRAGMA synchronous=NORMAL;')

data = [(1, 'foo', 100), (2, 'bar', 200), ...]
conn.execute('BEGIN')
try:
    conn.executemany(
        'INSERT INTO events(id, name, value) VALUES(?, ?, ?)',
        data
    )
    conn.commit()
except Exception:
    conn.rollback()
    raise

这个案例里，几千行的入库在未优化前如果是逐条自动提交，耗时可能是几秒；改成单事务批量提交后，瞬间降到几十毫秒。数据吞吐的差距能到几十倍，完全不夸张。

另外，生产环境里"存在就更新、不存在就插入"的场景特别多。SQLite 3.24以上支持UPSERT语法，千万别再用"先SELECT判断，再INSERT或UPDATE"这种两步走了，那是竞态条件和性能瓶颈的双重来源。

sql复制INSERT INTO user_points(user_id, points)
VALUES(?, ?)
ON CONFLICT(user_id) DO UPDATE SET
    points = excluded.points,
    updated_at = strftime('%s', 'now');

这段SQL在有user_id唯一约束的前提下，一条语句就完成了"存在就更新，不存在就新增"，并且是原子操作，不需要额外开事务锁。底层处理C++代码保存JSON数据时也可以用类似思路，把JSON串作为TEXT字段写入，再配合SQLite的json_extract函数做条件查询，完全够生产用。

4.3 连接管理的正确姿势

在我审查过的很多SQLite生产问题里，连接使用不当占了一半以上。最常见的错误是：每次操作都open一次连接再close，或者反过来一条连接长期不释放还跨线程使用。SQLite本身没有网络数据库那样昂贵的"建连"过程，实际开销很小，但频繁open/close会反复执行文件打开、锁初始化等操作，高并发下反而放大开销。更推荐的做法是：进程内维护一个连接池或至少复用长连接，但每个线程保持自己专用的连接实例，不在线程之间共享同一个连接对象。

对于写操作，如果应用存在多个线程同时写，建议在业务层用一个单线程的写队列把写请求串行化。这样一方面避免大量SQLITE_BUSY重试，另一方面也能让SQLite的写吞吐保持稳定。我在第3章的调度引擎里就是这么干的：所有状态更新先放入channel，由一个专门的goroutine负责落库，读请求走只读连接。这个架构让我几乎再也没碰上过"database is locked"错误。

5. 生产环境最容易翻车的五个坑与完整排查链路

SQLite生产翻车的点其实很集中，而且特征明显。我不直接给答案，先带着大家走一遍我真实遇到过的排查链路，下次你在日志里看到类似现象，能快速定位。

5.1 症状："database is locked"长期霸屏

现象：应用在某个时间点后，日志里频繁出现SQLITE_BUSY或database is locked，重启服务能好一阵子，但过段时间又复发。

我当时的排查顺序是这样的：

1. 先看所有连接是否都设置了busy_timeout。如果某个连接没有设置，它会在锁冲突时立刻抛错。检查后发现，新加入的一个后台任务线程没有执行任何PRAGMA初始化，用的是默认值，于是它一遇到写锁直接报错。
2. 再查是否有连接持有了写事务但长期没有提交。我去应用侧给每个连接加上了活跃事务日志，结果发现有个定时任务的回调里，事务内嵌了一次远程HTTP调用，网络超时拖了十几秒，事务也一直没提交，导致所有其他写请求排队。
3. 最后使用PRAGMA database_list和threading日志确认了每个连接的归属线程，找出那根"连接串线程"的隐患。

这个问题的修复并不复杂：给所有连接统一设置busy_timeout，同时把HTTP远程调用挪出事务，确保事务内只做数据库操作。另外加了一条铁律：所有连接建立后必须执行相同的初始化SQL，不许自己单独另起连接干私活。

5.2 症状：wal文件暴涨占满磁盘

现象：数据库主文件不大，但同目录下的app.db-wal涨到了好几个GB，最后把磁盘撑爆。

WAL文件增长的根本原因数据库是checkpoint没有跟上写入速度，或者有读事务一直不关闭，阻塞了checkpoint从WAL文件头部开始覆盖。排查时我先看了wal_autocheckpoint参数，发现它被某次变更意外重置回默认值但主库还是照常写入，WAL积累到一定页数才合并，于是增长速度过快。接着我用长事务查询定位到一条"开始时开启了事务，循环处理每条记录，最后才统一提交"的读取代码。这段代码在执行期间持有了一个读快照，导致checkpoint无法推进，WAL越积越大。

处理方案包括：确保wal_autocheckpoint按预期工作，同时定期执行PRAGMA wal_checkpoint(TRUNCATE)；从代码层严格要求"只读查询如果不是必须，就不要显式开启事务"；长事务里禁止夹杂耗时的业务逻辑。修复后WAL文件长期稳定在几MB以内。

5.3 症状：用文件复制备份，恢复出来的库是坏的

这条非常经典。WAL模式下，数据库的完整状态同时存在于主库文件和wal文件里。直接执行cp app.db backup.db，往往只复制了主库文件，没复制wal文件，或者复制了wal但不是当前最新状态。等恢复时打开备份，要么缺失最近提交的数据，要么直接报malformed。我第一次踩这个坑时还以为SQLite的备份机制有问题，后来仔细读文档才知道：WAL模式下不能裸拷数据库文件作为在线备份。

正确的备份方式至少有三种：

• 使用sqlite3客户端执行.backup命令。
• 在应用侧调用在线备份API（例如C语言的sqlite3_backup_step、Python的sqlite3.Connection.backup）。
• 先执行PRAGMA wal_checkpoint(TRUNCATE)，把WAL内容合并回主文件，再对主库文件做文件拷贝，但拷贝期间要保证没有新写入。

我在文章后面会专门给一套生产备份脚本，这里先提醒一句：备份必须通过SQLite认可的机制执行，绝不能靠文件系统快照或直接复制了事，除非你能保证数据库处于完全静默状态。

5.4 症状：库文件放在NFS/网络盘后出现各种诡异错误

现象：SQLite跑得好好的，运维为了"高可用"把数据目录挂载到NFS共享存储，结果应用开始随机报SQLITE_CORRUPT、SQLITE_IOERR或者database disk image is malformed。

SQLite的锁机制依赖底层文件系统对POSIX文件锁的可靠实现。NFS、CIFS这类网络文件系统的锁语义并不完全可靠，而且网络延迟会让锁等待时间明显变大，极端情况下多个客户端同时打开同一个库文件，会产生不可预期的文件损坏。SQLite官方文档也明确不建议把数据库文件放在网络文件系统上。我后来把数据目录改回本地磁盘，所有诡异问题一夜消失。

这个坑的教训是：SQLite的"网络化"不能靠把库文件放到共享存储里实现。如果多节点必须访问同一份数据，请换真正的数据库中间件，而不是去挑战数据库底层对POSIX语义的依赖。

5.5 症状：云主机/容器环境kill后，数据库打不开

现象：服务被强制杀掉或者宿主机突然重启，再见库文件时PRAGMA integrity_check报了错，或者打开时提示需要恢复。

SQLite设计上对进程崩溃是有抵抗力的，但抵抗的前提是操作系统没有被突然断电，且文件系统数据没有乱序落盘。云主机环境下如果开启了磁盘缓存或者底层存储掉电保护不到位，重启后残留的热页缓存和文件实际状态不一致，就可能损坏数据文件。这里有一个我在生产环境学到的额外经验：SQLite的WAL模式在进程被kill -9后通常能自动恢复，很多"损坏"其实是应用没有重新执行恢复流程，或者服务被OOM killer杀掉时正好有一些页面没有写完。

无论如何，一旦遇到打不开的库，千万先复制一份只读副本到安全位置，再做恢复操作。尝试用sqlite3对副本做PRAGMA integrity_check，如果返回ok，直接继续用副本；如果报错，再考虑用.recover命令尽量导出可读数据。这些操作都应在故障库的副本上进行，不要在原始文件上反复折腾。

6. 容器化部署SQLite的隐藏要求：Docker中的数据与权限

现在很多新项目直接以容器方式承载SQLite应用。容器的便利性和SQLite的单机特性放一起，看着挺搭，但实际部署时有一些隐藏要求，不处理好会折腾得很难受。

6.1 数据卷：必须用独立volume，别写在容器可写层

Docker容器一旦删除，容器可写层里的数据就跟着没了。SQLite数据库文件如果只是放在容器内部路径，哪怕运行中一切正常，一旦docker rm重建，全部业务数据直接消失。正确做法是用Docker命名卷（named volume）或者绑定挂载宿主机目录，把数据库文件所在的目录独立出来。

yaml复制services:
  app:
    image: myapp:2025.01
    volumes:
      - app-data:/data
    healthcheck:
      test: ["CMD", "sqlite3", "/data/app.db", "PRAGMA integrity_check;"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 20s

volumes:
  app-data:

在命名卷模式下，Docker负责管理卷的生命周期，删除容器不会动卷里的数据。我特别强调一下：SQLite文件目录和数据卷要一一对应，不要让应用把数据库文件写到容器根目录，否则后面做持久化迁移会非常痛苦。

6.2 文件权限：注意uid/gid漂移和初始化顺序

容器启动时如果以root运行，首次启动会创建数据库文件，文件owner是root。等以后调整容器以非root用户运行时，应用进程没有权限访问已经存在的root-owned文件，就会出现SQLITE_CANTOPEN。这个问题通常在"第一次部署正常，二次发布后启动失败"时才暴露，特别坑。

我的建议是：在Dockerfile或部署编排里明确指定运行用户，并且使用entrypoint脚本在所有应用启动之前先创建数据目录、调整owner、并执行必要的数据库初始化。不要依赖应用进程去处理权限，进程启动后往往已经没有权限改了。

6.3 与docker-compose生产部署相关的额外细节

如果使用docker-compose在生产环境部署，还有一个比较隐蔽的坑：多个容器副本挂在同一个命名卷上，同时访问同一个SQLite文件。这在SQLite里是不能接受的，但docker-compose默认允许你replicas: 3，结果三个容器抢同一个库，会频繁出现锁等待甚至损坏。生产环境使用SQLite时docker-compose服务只能部署单副本，或者明确做状态ful的host约束，保证同时间只有一个实例挂载写该数据库文件。

另外，进程被docker stop的时候，容器会收到SIGTERM然后进入宽限期，这个宽限期内应用应该主动关闭所有SQLite事务、执行checkpoint、释放连接。如果你的应用没有注册优雅停机逻辑，SIGTERM后直接被SIGKILL，WAL模式下虽不至于损坏，但频繁的强制终止会让WAL文件恢复流程反复执行，影响启动时间，极端情况也会增大风险。

容器化部署SQLite还有一个容易被忽略的点：SQLite对CPU指令集不敏感，但对SQLite版本敏感。不同版本的数据库文件格式完全兼容，但一些新语法和WAL行为有差异。因此部署镜像里最好固定SQLite库版本，避免基础镜像更新后SQLite版本跳变导致的隐性问题。我习惯在服务启动日志里打印sqlite3.sqlite_version，方便出问题时第一时间核对版本。

7. SQLite生产运维的最后一道防线：备份、监控与恢复演练

很多人以为SQLite零运维就是真的不用管了。实际上单文件数据库的运维虽然比网络数据库轻很多，备份和恢复依旧是不可省略的底线。我在生产环境吃过一次亏之后，把SQLite的运维体系补齐成了一套可以照抄的清单。

7.1 在线备份的正确操作方式

SQLite支持在线备份，意思是在数据库持续读写的情况下，也能做出一份一致性快照。命令行下最推荐的方式是：

bash复制sqlite3 /data/app.db ".backup '/backup/app_$(date +%Y%m%d_%H%M%S).db'"

这条命令内部通过备份API读取数据库和WAL的完整状态，生成一个新的一致性的备份文件，执行期间不需要停服务，也不会挡住正常读写。Python应用侧需要编程执行时，可以这样：

python复制import sqlite3

source = sqlite3.connect('/data/app.db')
backup = sqlite3.connect('/backup/app_backup.db')
with backup:
    source.backup(backup)
backup.close()
source.close()

无论哪种方式，备份完成后都应该对备份文件做一个完整性检查，避免备份过程本身有问题却没人发现。

7.2 定期做恢复演练，而不仅仅是备份

数据库领域有个老话叫"没做过恢复演练的备份都是心理安慰"。我每两周就会从备份机挑一个最近的备份文件，在一个隔离目录里恢复并执行：

sql复制PRAGMA foreign_keys=ON;
PRAGMA integrity_check;

integrity_check结果必须返回ok，然后随便做几条业务查询，确认关键表行数和最近更新时间符合预期。这一步能发现两类问题：一是备份文件本身已经损坏，二是数据库schema变更后备份脚本没有同步覆盖新表。如果等到真正故障时才发现备份不可用，那整条数据安全体系就形同虚设了。

备份文件的保存周期我一般遵循3-2-1原则：本地保留至少3份，使用至少2种不同介质或存储位置，其中1份放在独立机房或云存储区域。SQLite备份文件直接跨区域复制到对象存储很轻量，一个几百MB的库压缩后通常几十MB，传输成本完全可控。

7.3 监控该关心哪些指标

SQLite没有内置的网络端口和状态页，监控信息大多要自己从应用层取。我总结出五个必看的监控项：

• 数据库文件大小与WAL文件大小：文件突然暴涨通常意味着checkpoint失效。
• SQLITE_BUSY错误次数：应用侧统计到busy错误增加，说明锁竞争进入危险区间。
• 单事务提交耗时：事务提交时间超过100毫秒连续多次出现，需要排查磁盘IO和锁冲突。
• 慢查询数量：超过阈值的查询次数上升，优先检查索引和缓存配置。
• 进程内连接数量与长期未提交事务：这是很多隐藏问题的源头。

这些指标不一定非要接入Prometheus那套体系，哪怕先打到日志统计里也可以。关键是有一个持续观测的手段，出了问题能往前翻数据，而不是两眼一抹黑。

7.4 关于备份中数据安全的一句提醒

数据库备份文件包含的是完整业务明细数据，绝对属于敏感数据。我把备份文件放到对象存储时会单独设置桶权限，不允许公共读，同时在传输链路开启加密。团队内部约定备份文件访问需要走审批，本地的备份目录也要限制操作系统用户权限，避免普通应用账号能读到整库备份。这些细节不属于SQLite本身的问题，但生产事故往往不是单点技术失误，而是备份文件管理不当引发更大的麻烦，越是轻量级数据库越容易在这一点上被忽视。

我在实际维护过程中还有一个小技巧：把SQLite备份任务的执行日志和校验结果集中到一个统一报表里，每周自动发送一次。这个报表里不仅包含备份文件列表和大小，还会把integrity_check的执行结果带上。多个库、多台机器都能一眼看清备份健康状态，比出了问题再翻终端记录高效得多。

回到选择SQLite这件事本身。每次项目立项，我都会问自己三个问题：这份数据真正需要几台机器同时写？存量数据的量级是多少？团队能接受的运维复杂度是什么？只要这三个问题的答案落在单机、关系型、低频并发的区间里，SQLite就是我第一个考虑的对象。它不是一种退而求其次的选择，而是一个值得被认真对待的生产级存储方案，前提是你愿意花时间理解它的锁模型、WAL机制和备份策略。希望这篇从实战里泡出来的总结，能让你在下一次评估存储方案时做出更清醒的决策。