必须用SQLite WAL模式+显式事务控制，否则断电瞬间大概率丢最后几条数据；因环形缓冲区纯内存，断电即丢失，而WAL模式通过预写日志和原子提交保障掉电安全，配合BEGIN IMMEDIATE/COMMIT批量写入与云端确认后删除，确保数据不丢。
必须用 SQLite WAL 模式 + 显式事务控制，否则断电瞬间大概率丢最后几条数据。
为什么不能只靠内存环形缓冲区
环形缓冲区（Ring Buffer）写入快、无锁，但它是纯内存结构。一旦网关进程崩溃、设备断电或看门狗复位，里面所有未落盘的数据就彻底消失。你在雷雨天丢掉的那 30% 数据，几乎全发生在这里——MQTT 发布失败后没及时转存，而是等“下一轮重试”，结果断网 6 小时，缓冲区早已被新数据覆盖。
真实工业现场不接受“理论上能扛住突发流量”这种说法，它只认“掉电后重启，SQLite 文件里还剩多少条”。
SQLite WAL 模式是唯一靠谱的选择
普通 SQLite 的 DELETE/INSERT 在主数据库文件上直接操作，写入过程中若断电，文件极易损坏；而 WAL（Write-Ahead Logging）模式把变更先写进 wal 文件，主文件保持只读，只有在显式 COMMIT 时才原子合并。这意味着：
• 即使进程中途 kill -9 或断电，WAL 文件内容仍可被下次打开时自动回放
• PRAGMA synchronous = NORMAL + PRAGMA journal_mode = WAL 是最低安全底线
• 必须手动控制事务：每批写入（比如 50 条）包裹在 BEGIN IMMEDIATE / COMMIT 中，不能依赖 autocommit
常见错误写法：
• 用 std::ofstream 直接写 JSON 文件——没事务、没 fsync、没崩溃恢复能力
• 开启 WAL 但没设 synchronous = NORMAL，性能掉一半还未必更安全
• 把所有采集点塞进一张大表，没建 CREATE INDEX ... ON timestamp，补传时查 10 万条要 3 秒
立即学习“C++免费学习笔记（深入）”；
数据表结构和写入节奏怎么配
别一上来就设计“通用遥测表”。工业现场数据有强模式：每个设备 ID、每个寄存器地址、每个时间戳都是确定的。推荐按设备+协议维度分表，例如：
• 表名：modbus_192_168_1_10（IP 地址脱点）
• 字段：id INTEGER PRIMARY KEY AUTOINCREMENT, ts INTEGER NOT NULL, reg_addr INTEGER, value REAL, quality TINYINT
• 写入节奏：
- 采集线程每 100ms 收一条，攒够 20 条再批量 INSERT INTO ... VALUES (...), (...), ...
- 每次批量写入前调用 sqlite3_exec(db, "BEGIN IMMEDIATE", ...)
- 批量完成后立刻 sqlite3_exec(db, "COMMIT", ...)
- 避免单条 INSERT，否则 WAL 日志膨胀快、I/O 次数爆炸
补传成功后怎么安全删数据
补传不是“发完就删”。必须等云端返回明确确认（比如 HTTP 200 + 含 "ack_id": "xxx" 的 JSON），再执行 DELETE FROM modbus_192_168_1_10 WHERE id 。关键点：<br>• 删除语句也必须包在事务里，和补传日志记录（如写入 <code>acked_log 表）一起提交
• 绝对不要用 DELETE FROM ... WHERE ts ——设备本地时钟漂移时会误删<br>• 建议加一个 <code>status TINYINT DEFAULT 0 字段，0=待发，1=已发未确认，2=已确认，删之前先查状态
最容易被忽略的是 WAL 文件残留：SQLite 不会自动清理已提交的 WAL，得靠 PRAGMA wal_checkpoint(TRUNCATE) 主动触发。建议在每次补传完成且删除旧数据后调用一次，防止 SD 卡空间悄悄涨满。
