核心判断
这套配置下,"数据可恢复"和"数据合并进主库"是两个不同的时间点,问"最长落盘时间"必须分清楚问的是哪个。直接给出三层答案:
一、关键参数解读
三个参数决定了三个不同的窗口:
参数 | 决定的是 | 影响 |
isolation_level=None | 何时形成一个 commit | autocommit → 每条语句 1 个事务 |
synchronous=FULL | commit 时是否 fsync WAL | FULL → 每次 commit 都 fsync |
wal_autocheckpoint=1000 | WAL → 主 DB 何时合并 | 1000 页(默认 4KB/页 = 4MB)触发 |
二、三层"落盘时间"分别是多少
第 1 层:数据进入 WAL 文件并 fsync(= 掉电可恢复)
synchronous=FULL+ autocommit → 每次execute()返回前都已经 fsync(WAL)
- 最长延迟 ≈ 一次 fsync 的耗时
- eMMC 上典型 fsync 耗时:5~50ms(工业级带 PLP),消费级 SD 可能飙到 100~500ms
- 掉电安全性在这一层就已经建立:
execute返回 = 数据已在 NAND 上(或至少在 eMMC 的 PLP 受保护 cache 中)
这是 SQLite WAL 的核心承诺:commit 返回那一刻,数据是 durable 的。后续 checkpoint 不影响可恢复性,只影响"在哪里"。
第 2 层:数据从 WAL 合并到主 DB 文件
- 由
wal_autocheckpoint=1000触发,默认是 PASSIVE checkpoint
- 触发时机:WAL 累计写满 1000 帧时,下一次 commit 在 fsync 后顺手做一次 checkpoint
- 时间上界:取决于写入速率
- 写 1KB/次 × 4 帧/KB(取决于 page size)→ 大约几千次 commit 才触发
- 慢速写入(比如 1 次/min)可能 几小时甚至几天都不 checkpoint
- 这不是问题:WAL 在 commit 时已 fsync,checkpoint 只是"整理",不是"持久化"
第 3 层:eMMC 内部 cache → NAND cell
- 即便
fsync返回,数据 不一定真在 NAND cell 上,可能在 eMMC 控制器的 DRAM cache 里
- 工业级 eMMC 带 PLP(Power Loss Protection) = 内部超级电容,掉电时把 cache flush 到 NAND,100~500μs 级
- 消费级 eMMC / SD 卡 没有 PLP = fsync 返回但 cache 数据仍可能在掉电时丢
- 这一层是硬件层,SQLite 管不到
三、最长不落盘时间的具体上界
场景 | "落盘"定义 | 最长延迟 | 关键依赖 |
autocommit 单语句 | WAL fsync 完成 | 5~50ms (工业 eMMC) | fsync 性能 |
显式事务( BEGIN…COMMIT) | WAL fsync 完成 | 事务持续时间 + 一次 fsync | 事务多长就多长 |
WAL → 主 DB 文件 | 主 .db 文件被更新 | 几分钟到几小时(取决于写入速率) | autocheckpoint 阈值 |
NAND cell 真落地 | 断电不丢 | 100μs~∞ | 是否有 PLP |
四、实战中真正要担心的不是"延迟",而是这两个坑
五、一句话总结
这套配置下,单条 execute 的"最长不落盘时间"≈ 一次 fsync 耗时(工业 eMMC 约 5~50ms);WAL 合并回主库的延迟可达数小时,但与可恢复性无关;真正的"硬不可控延迟"在 eMMC 内部 cache,靠 PLP 解决,SQLite 管不到。
如果场景是"必须 100ms 内绝对落到 NAND",答案是:单靠这套 SQLite 配置不够,必须叠加 工业级 eMMC + PLP + 文件系统 commit 间隔调小。
