在移动端应用、多端数据同步、离线缓存等场景中，SQLite数据库文件的体积往往从几MB增长到几百MB。如果每次同步都完整拷贝整个数据库文件，既浪费带宽又拖慢速度。更合理的做法是：先为数据库建立一份快照作为基准，之后只提取发生变化的行，生成增量包进行传输和合并。本文将以一个完整的实战项目为例，讲解SQLite中快照与增量更新的设计与实现。
一、快照的基本原理与生成方式
快照的本质是“在某个时间点对数据状态的完整记录”。在SQLite中有几种常见的快照生成方式，各有适用场景。
第一种是文件级快照，即直接复制数据库文件。SQLite默认使用回滚日志模式，写入过程中直接复制文件可能得到损坏的副本。稳妥的做法是先执行PRAGMA wal_checkpoint(TRUNCATE)将WAL日志合并回主文件，或者使用官方提供的备份API：sqlite3_backup。在命令行中对应的工具是.backup命令，它会在获取读锁的情况下安全地复制数据。
-- 使用命令行工具生成安全快照 sqlite3 app.db ".backup snapshot_base.db" -- 或者在代码中先合并WAL再复制 PRAGMA wal_checkpoint(TRUNCATE);
第二种是逻辑快照，即通过.dump导出全部SQL语句，保存为文本。这种方式的可读性好，便于diff比较，但对于大库来说生成和恢复都较慢，一般用于调试或小型数据。
第三种是版本号快照，这也是增量更新的基础。做法是给每张业务表增加一个版本字段，每次修改数据时递增一个全局版本号并写入该行。这样“快照”就退化成了一个整数：版本号N。之后只需要查询版本号大于N的行，就能得到所有变化的数据。下面是建表示例：
-- 全局版本表，每次数据变更时递增
CREATE TABLE IF NOT EXISTS meta_snapshot (
id INTEGER PRIMARY KEY CHECK (id = 1),
version INTEGER NOT NULL DEFAULT 0
);
INSERT OR IGNORE INTO meta_snapshot (id, version) VALUES (1, 0);
-- 业务表带版本字段
CREATE TABLE orders (
rowid INTEGER PRIMARY KEY AUTOINCREMENT,
order_no TEXT NOT NULL,
amount REAL,
updated_version INTEGER DEFAULT 0,
deleted INTEGER DEFAULT 0
);
二、基于触发器的变更追踪方案
如果表结构不方便修改，或者希望变更记录与业务数据解耦，触发器加日志表是更通用的方案。其核心思路是：为每张需要同步的表创建三个触发器，分别在INSERT、UPDATE、DELETE时向日志表写入一条记录，记录发生变化的rowid和操作类型。
CREATE TABLE change_log (
id INTEGER PRIMARY KEY AUTOINCREMENT,
table_name TEXT NOT NULL,
row_id INTEGER NOT NULL,
op_type TEXT NOT NULL, -- 'I'插入 'U'更新 'D'删除
created_at INTEGER NOT NULL
);
CREATE TRIGGER trg_orders_ai AFTER INSERT ON orders
BEGIN
INSERT INTO change_log (table_name, row_id, op_type, created_at)
VALUES ('orders', NEW.rowid, 'I', strftime('%s','now'));
END;
CREATE TRIGGER trg_orders_au AFTER UPDATE ON orders
BEGIN
INSERT INTO change_log (table_name, row_id, op_type, created_at)
VALUES ('orders', NEW.rowid, 'U', strftime('%s','now'));
END;
CREATE TRIGGER trg_orders_ad AFTER DELETE ON orders
BEGIN
INSERT INTO change_log (table_name, row_id, op_type, created_at)
VALUES ('orders', NEW.rowid, 'D', strftime('%s','now'));
END;
这套方案有三个明显优点。第一，对业务代码完全透明，上层不需要关心同步逻辑，任何途径写入的数据都会被记录。第二，日志表本身也可以做增量清理，同步完成后删除旧日志，控制体积。第三，删除操作也能被捕获，这是单纯靠时间戳字段难以做到的，因为行被删掉后时间戳也随之消失。
它的缺点同样需要注意：触发器会给每次写入增加额外开销，在每秒数千次写入的高频场景下性能会下降；日志表本身也占用空间。因此触发器方案适合中等写入频率、表结构固定、需要通用性的项目。如果追求极致性能，建议采用应用层维护版本号的方式，在业务代码的写入路径中顺带更新版本字段。
三、增量包的生成与合并
有了变更追踪，生成增量包就变得简单。以版本号方案为例，客户端记录上次同步的版本号N，服务端查询updated_version > N的所有行，连同当前最大版本号一起打包返回。合并时，客户端在一个事务内执行UPSERT操作，并将本地版本号推进到服务端返回的最大值。
-- 服务端：提取自版本N以来的变化行
SELECT rowid, order_no, amount, deleted, updated_version
FROM orders
WHERE updated_version > :last_sync_version
ORDER BY updated_version
LIMIT 5000;
-- 服务端：返回本次同步的高水位
SELECT version FROM meta_snapshot WHERE id = 1;
-- 客户端：在同一事务内合并并推进版本
BEGIN IMMEDIATE;
INSERT INTO orders (rowid, order_no, amount, deleted, updated_version)
VALUES (:rowid, :order_no, :amount, :deleted, :uv)
ON CONFLICT(rowid) DO UPDATE SET
order_no = excluded.order_no,
amount = excluded.amount,
deleted = excluded.deleted,
updated_version = excluded.updated_version
WHERE excluded.updated_version > orders.updated_version;
UPDATE meta_snapshot SET version = :new_version WHERE id = 1;
COMMIT;
这里有几个工程细节值得强调。首先，合并和版本推进必须放在同一个事务中，否则中途失败会导致数据已写入但版本未推进，下次同步会重复处理，虽然幂等设计可以容忍重复，但会浪费性能。其次，UPSERT语句中的WHERE excluded.updated_version > orders.updated_version条件用于防止旧数据覆盖新数据，这在多客户端并发同步时非常关键。最后，删除同步建议采用软删除标记（deleted字段），同步完成一段时间后再做物理清理，避免删除信息在传输过程中丢失。
对于大量数据需要跨设备迁移的情况，还可以结合ATTACH语法直接在两个数据库文件之间搬运数据，这比逐行导出再导入快得多：
ATTACH DATABASE 'increment_pack.db' AS inc; BEGIN; INSERT OR REPLACE INTO main.orders SELECT * FROM inc.orders; DETACH DATABASE inc; COMMIT;
四、方案对比与选型建议
下表汇总了文中提到的几种方案的特性，便于根据项目实际情况选择：
| 方案 | 实现复杂度 | 性能开销 | 是否捕获删除 | 适用场景 |
|---|---|---|---|---|
| 文件级备份（backup API） | 低 | 高（全量复制） | 是 | 整库备份、灾备 |
| 版本号字段 | 中 | 低 | 否（需软删除配合） | 高频写入、自研同步 |
| 触发器加日志表 | 中 | 中 | 是 | 表结构固定、通用同步 |
| dump导出文本 | 低 | 高 | 是 | 调试、小型数据 |
实践中常常是组合使用：定期（例如每周）执行一次文件级全量快照作为基准兜底，日常同步则走版本号或触发器增量通道。这样即使增量链路出现异常，也能通过最近的快照快速恢复。需要注意的是，任何依赖rowid的方案都要保证主键在同步双方的一致性，建议统一使用AUTOINCREMENT或在服务端集中分配，避免不同设备各自生成的rowid发生冲突。
总结来说，SQLite的快照与增量更新并没有想象中复杂：快照负责建立基准和兜底恢复，版本号或触发器负责捕获细粒度变更，增量包负责高效传输，事务保证合并的原子性。把这几个环节搭好，即使是单机数据库，也能支撑起可靠的多端数据同步体系。