1. 为什么上位机项目绕不开数据持久化——先看清你的数据模型做上位机开发的人大多经历过这种场面PLC、板卡或者仪器仪表传回来的数据在界面上跑得飞快曲线、数字、开关量全部正常但只要一断电或者软件重启历史数据就全部蒸发。客户验收时随口一句“我想看看上周那台设备某几个小时的曲线”你就得当场想办法捞数据捞不出来就是事故。反过来我也见过不少新入行的同事觉得“数据持久化嘛不就是把每条数据往数据库里怼”。于是采集线程里每来一条就执行一次 INSERT结果界面卡死、数据库文件膨胀、程序越跑越慢。问题不在于 SQLite 本身行不行而在于没有想清楚“什么数据、什么频率、存多久、谁来读”这四件事。1.1 上位机里的三类数据性格完全不同我在实际项目里习惯把上位机的数据分成三类高速采集类数据典型是振动波形、电流瞬态值、位置误差、编码器反馈。这类数据采样率从 100Hz 到几十 kHz 都很常见每条数据可能只有几个到几十个字节但一秒钟就能产生几千到几万条记录。这类数据如果直接落盘磁盘 IO 很快就成为瓶颈更麻烦的是它们通常用于实时曲线显示和报警判断写磁盘的速度根本跟不上采集节奏。状态与报警类数据比如设备启停信号、故障码、温控开关动作、操作记录。这类数据频率低、每秒几条甚至每分钟几条但价值高、需要长期保留、经常会被检索。客户问“昨天凌晨三点那台设备为什么停机”时查的就是这类数据。配置与工艺参数类数据比如配方、PID 参数、坐标补偿值、设备型号。这类数据量小、改动不频繁但是绝对不能丢。如果程序重启后参数丢失整个设备都可能变成“工厂门禁都打不开”的状态。这三类数据的访问模式完全不同选型时如果用一套方案硬套要么过度设计要么性能翻车。我见过有人为了让 10kHz 的波形数据实时展示硬是往 SQLite 里高频写结果数据库还没崩UI 先卡死了也有人因为省事把所有参数都扔在一个 CSV 文件里结果设备运行久了文件几个 G打开都费劲。1.2 持久化发生在采集闭环的哪个位置上位机从硬件取数到界面展示中间至少经过采集、解析、处理、显示、存储几个环节。持久化不应该仅仅放在采集线程里面搞“实时同步写”而应该把它视为整条数据处理链路上的一层。我通常建议画一张简单的数据流图硬件设备 - 采集线程 - 原始数据缓存 - 实时计算/曲线显示 - 存储层。采集线程只负责把数据丢进缓存区显示模块从缓存区读数据做实时渲染存储层则按照设定策略把缓存区里的数据批量写入归档。这样无论是 SQLite 还是内存数据库都只是一个“后端角色”不会反向拖累前端采集。其实很多所谓“选型困难”根源在于没有给每种数据分配不同的车道。高频数据走内存缓冲低频记录直接写库配置参数用单独的表管理并定期备份这就是最朴素的分层思路。下面我把 SQLite 和实时内存数据库分别拆开讲再给出组合用法。2. SQLite 在上位机里的定位与四个关键配置2.1 单机嵌入式数据库的“部署友好”压倒一切接触过工控现场的人都知道客户那台工控机上的软件环境有多“原生态”。有的机器连 VC 运行库都没装全更别提 MySQL、PostgreSQL 那套独立服务。上位机软件要是在部署环节还得装一个数据库服务端项目经理的脸当场就能拉下来。SQLite 最大的优势是它没有服务端数据库就是软件目录下的一个文件。C# 里用 Microsoft.Data.Sqlite 这个官方库发布时带上运行时需要的原生二进制客户机器上只要能跑 .NET数据库就能用。升级、备份、迁移都极其简单关掉程序、复制文件、完事。这一点在工控场景里是实打实的“免维护”。有些同事会说“我用 CSV 不也一样吗不就是写文件吗”。数据量小的时候是差不多但一旦涉及按时间段查询、条件过滤、跨天统计CSV 的处理就非常痛苦。SQLite 至少给了你标准 SQL、索引、事务和并发控制哪怕你只用到其中两成功能收益也已经明显超出文件方案。2.2 让 SQLite 别卡脖子WAL、busy_timeout、synchronous、连接池不少人第一次用 SQLite 时被“database is locked”坑过然后就直接给 SQLite 判了死刑。其实这个错误大多数情况下不是 SQLite 不行而是你把滚珠轴承当锤子使。SQLite 默认的 rollback journal 模式下读和写会互相阻塞写入时甚至可能阻塞整个数据库文件的读取。解决这个问题最常用的手段是开启 WAL 模式也就是 Write-Ahead Logging。开启之后写入先落到一个独立的-wal文件读操作依然可以从主库文件读取读写并行能力大幅提升。我在代码里一般这样设置using var cmd conn.CreateCommand(); cmd.CommandText PRAGMA journal_modeWAL;; var mode cmd.ExecuteScalar()?.ToString(); // 正常返回值应当是 wal注意要检查返回值如果返回的不是wal说明当前环境下写入可能被限制或者数据库处于其他状态。WAL 模式启用后你会在数据库文件旁边看到.wal和.shm两个辅助文件这都是正常的程序正常关闭并 checkpoint 后会合并回主库文件。第二个关键配置是busy_timeout。这个参数的作用是当数据库文件被其他连接锁住时当前操作最长等多久再报错。我一般设置为 3000ms写入线程争取任务时如果遇到短时占用会自动等待而不是立刻抛出SQLITE_BUSY异常using var cmd conn.CreateCommand(); cmd.CommandText PRAGMA busy_timeout3000;; cmd.ExecuteNonQuery();第三个参数是synchronous。默认是 FULL每一次写操作都要等待数据落盘安全但速度偏慢。数据量大的批量写入场景我会在事务里临时设置为 NORMAL。NORMAL 模式下 WAL 机制本身仍能保证数据库崩溃时数据不会损坏只是极端掉电场景下可能丢失最近一小段已提交数据。对于绝大多数工业数据归档来说这个代价可以接受。第四个要点是连接串。很多人写 SQLite 代码喜欢每次操作都新建一个连接用完就关这在数据量大的时候非常浪费。Microsoft.Data.Sqlite 支持连接池要在连接串里显式开启var connStr new SqliteConnectionStringBuilder { DataSource dbPath, Mode SqliteOpenMode.ReadWriteCreate, Cache SqliteCacheMode.Shared, Pooling true }.ToString();连接池加上共享缓存能让并发读写场景下的锁冲突明显减少。但也要注意连接池里的物理连接如果长时间空闲WAL 文件可能不会被及时 checkpoint所以长时间运行的程序最好定期执行一下PRAGMA wal_checkpoint(TRUNCATE);或者干脆让程序重启时自动 checkpoint。2.3 数据库文件损坏与恢复别指望每次都靠备份工业现场断电从来不讲道理Windows 异常关机、工控机蓝屏、USB 被拔都有可能发生。SQLite 虽然有事务保护但也不能 100% 免疫文件损坏。我处理过的案例里最常见的是.wal文件异常残留导致主库打不开或者是数据库文件被第三方工具半路打开改坏了。遇到这种问题我一般先从备份恢复所以我的程序里会保留最近三份数据库备份文件这是最后一道防线。如果连备份都没有也先别急着删除文件可以试试 SQLite 自带的恢复机制。使用 Db Browser for SQLite 时File - Export - Export to SQL file有时能把还能读出来的数据转成 SQL 脚本再用脚本重建数据库。命令行里可以用.recover命令但这两招的成功率取决于文件损坏程度别抱太大希望。2.4 一个顺手的小工具Db Browser for SQLite排查 SQLite 数据问题纯靠写代码看结果太慢了。我调试时基本都会开着 Db Browser for SQLite直接打开数据库文件查看表结构、索引和数据内容。它还支持执行任意 SQL方便我验证查询语句的写法。比如我要确认某张表的数据量、检查时间字段是否被正确存储、查看高频写入后 WAL 文件有没有异常膨胀直接用这个工具跑一条SELECT count(*) FROM samples WHERE ts ...就清楚了。还有一个很实用的功能是“Define Query”可以用它快速写一条带参数的查询语句调试复杂统计逻辑时省不少事。3. 实时内存数据库高频采集场景的“缓冲层”3.1 不是每个项目都需要一个真正的“内存数据库”名词聊到实时内存数据库很多人第一反应是 Redis、Memcached 这类独立服务。但在上位机项目里情况往往没有这么“重型”。工控现场就一台工控机客户不会同意你为了存数据再部署一个 Redis 服务更不会维护它。所以我在大多数项目里说的“实时内存数据库”其实指的是进程内维护的一套内存数据机构加上必要的并发控制和查询接口。它要解决的核心问题是高频数据进入系统后既要让显示模块毫秒级拿到数据又不能因为等磁盘 IO 拖慢采集。简单的ListSample不够用因为读写竞争会带来脏数据不加容量上限也不行进程跑一晚上会把内存吃光。所以一个合格的上位机内存数据层应该具备这几点无锁或轻量锁的并发读写、容量上限或过期淘汰机制、按时间窗口快速查询的能力。举个例子我的一个项目里32 个通道每 10ms 采集一条原始数据也就是每秒 3200 条记录。实时显示只需要最近 500 条点但整段曲线的原始数据可能要持续采集几个小时。如果把这些数据全部塞进内存假设每条记录包含时间戳和 32 个 float 和一个状态字节算下来约 140 字节一小时就是 50 万条占内存约 70MB还可以接受。但如果连续采集一天就是 1.7GB 内存这在工控机上已经不便宜了。3.2 轻量级内存数据库设计环形缓冲加时间窗口我的习惯是给高频采集数据做一个“容量有限、后续有机会落盘”的缓冲层。最常用的是环形缓冲容量固定新数据到来时如果缓冲满了最老的记录会被覆盖。这样内存占用永远有上限实时曲线永远能拿到最近的数据而落盘由另一个线程从缓冲里批量取走并写入 SQLite。还有一个更轻量的选择是直接用ConcurrentQueueT不需要自己实现锁。它的优势是 FIFO 语义非常自然缺点是没有容量上限要你自己在入队时检查Count并且手动丢弃队尾元素。实测下来采集线程入队、后台线程出队写库、主线程偶尔查最近数据这个组合在上位机场景里很稳。真正需要“数据库”语义的时候也就是要按时间范围查某个通道的值、要做聚合计算、要根据报警条件做复杂筛选时一个没有索引的容器就不够了。这时候我建议直接用时间序列的专用思路数据在内存中按通道分片每个分片内部是一个按时间排序的数组再保存一份分片的时间范围索引。查询时先定位到分片再做二分查找。这个实现并不复杂但性能比扫描全量列表高一个数量级。3.3 什么时候可以直接引入外部时序数据库如果项目本身就是一个数据密集型平台采集点很多、读取方也不只一个上位机那内部的“内存数据容器”确实不够用了。这种情况下可以选择正式的内存数据库或时序数据库。常见的有 Redis 搭配 Stream 数据类型处理时间序列也有 InfluxDB、QuestDB 这类专门为时序场景设计的存储。但我要提醒一句引入外部服务意味着你的项目从“单机软件”变成了“分布式系统”。权限管理、网络连接、客户端依赖、服务自动拉起、现场机器资源占用这些都要评估。上位机项目多数时候跑在 Windows 工控机上现场没有专职运维我不建议一上来就用重方案。先用进程内缓冲加 SQLite 扛住等数据量确实大到单机撑不住再考虑横向拆分这条路最稳。4. 选型对比持续写入的持久层到底怎么决策4.1 一张表看清 SQLite 和实时内存数据库的差异很多朋友纠结“SQLite 和内存数据库哪个好”其实答案取决于你拿它做什么场景。我整理了一张对比表基本覆盖了大多数上位机项目的考量点对比维度SQLite进程内实时内存数据库数据生命周期永久保存重启不丢临时保存重启即丢写入频率上限受磁盘 IO 和 WAL 影响一般每秒几千次批量写入没问题但不宜单条高频写微秒级可达每秒几十万次以上查询能力标准 SQL、索引、聚合、条件筛选都非常方便需要自己实现索引或按时间窗口扫描并发模型多连接需要 WAL 和 busy_timeout 配合单写多读最稳进程内共享内存用锁或无锁结构维护部署复杂度单文件无服务端发布简单无外部部署随程序启动可靠性事务机制掉电后较易恢复掉电丢数需要定期落盘兜底典型用途历史归档、报警记录、配置参数、报表查询实时曲线、高速采样缓冲、报警判断的临时数据集这张表其实已经暗示了一个结论这两者根本不是竞争关系而是接力关系。4.2 按写入频次和数据语义画一条决策线我在做选型时习惯先回答三个问题数据到达频次是多少如果每条数据间隔大于 100ms、每秒写入不超过几十条SQLite 完全可以直接写入不需要额外的内存缓冲。如果每秒几百条到几千条建议用内存缓冲积累一段时间再批量向 SQLite 落盘。如果每秒上万条甚至更高你要考虑是不是真的需要全部原始数据落盘还是只保留统计特征值就够了。数据需要保存多久、谁来读归档数据肯定要长期保存那就必须落到 SQLite 或者其他真持久化存储中。内存数据库里的数据只能作为临时态不能指望它撑起客户“查前三个月数据”的需求。数据是否需要跨进程共享上位机如果只有一个进程进程内缓冲完全够用。如果有多个上位机同时读同一批数据比如中控室和现场同时看一台设备就需要考虑真正的服务端存储。4.3 两层并用才是大多数项目的最终答案选 SQLite 和内存数据库从来不是“二选一”。我经手的项目里最终落地的方案基本都是两层内存层负责承接高频采集数据按时间窗口保存最近几分钟到几小时的数据用于实时曲线和报警判断SQLite 层负责把内存层的数据批量落盘用于历史查询、报表导出和故障追溯。典型流程是采集线程把数据写入内存缓冲后台落盘线程每隔一秒或几百毫秒从内存缓冲里取一批数据放进一个临时列表然后开启事务批量插入 SQLite。这样 SQLite 的写入频率大大降低每条 SQL 都能处理成百上千条记录效率和数据安全性都得到保障。同时内存层因为容量受限内存占用始终可控即使出现极端情况也只是丢了最近一小段来不及落盘的数据不会导致整个程序崩溃。这个架构看起来简单但很多项目一开始没做好问题往往出在没有人明确划分“哪些数据必须落盘、哪些数据只要内存”。我自己的原则是设备配置、报警事件、统计结果必须落盘原始波形按采样率评估能落盘就落盘不能落盘就保存特征值中间计算过程只放内存不用考虑持久化。5. 实战一套采集、缓存、落盘的参考实现5.1 一个真实项目参数我在一个自动化检测项目里处理过这样一台设备上位机通过串口和采集卡读取 32 通道的数据采样周期 10ms也就是每秒产生 3200 条记录。每条记录包含时间戳、32 个浮点通道值和一个状态码序列化后大概 140 字节。需求是实时曲线展示最近 30 秒的数据历史数据至少保留 30 天期间任何时间段都要能回放曲线程序异常退出或断电后已经采集的重要数据尽量不丢。这个需求下内存数据库和 SQLite 必须配合单靠任何一边都搞不定。5.2 数据库表设计与批量写入SQLite 部分我建的表结构大概长这样CREATE TABLE IF NOT EXISTS samples ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts INTEGER NOT NULL, ch0 REAL, ch1 REAL, ch2 REAL, -- 按实际通道数扩展 status INTEGER ); CREATE INDEX IF NOT EXISTS idx_samples_ts ON samples(ts);时间戳用 Unix 毫秒整数存储。不要用字符串时间或者默认的 ISO8601 文本格式字符串查询和排序性能都差一大截尤其在数据量上来之后。写入时不要把单条 INSERT 暴露给采集线程整理成一个批量写入方法。下面的代码用 Microsoft.Data.Sqlite 实现核心是“一个事务、一条命令、循环复用参数”public void WriteSamples(ListSampleData samples) { if (samples.Count 0) return; using var conn new SqliteConnection(_connectionString); conn.Open(); using var tx conn.BeginTransaction(); using var cmd conn.CreateCommand(); cmd.Transaction tx; cmd.CommandText INSERT INTO samples (ts, ch0, ch1, ch2, status) VALUES ($ts, $ch0, $ch1, $ch2, $status); ; var pTs cmd.Parameters.Add($ts, SqliteType.Integer); var pCh0 cmd.Parameters.Add($ch0, SqliteType.Real); var pCh1 cmd.Parameters.Add($ch1, SqliteType.Real); var pCh2 cmd.Parameters.Add($ch2, SqliteType.Real); var pStatus cmd.Parameters.Add($status, SqliteType.Integer); foreach (var sample in samples) { pTs.Value sample.TimestampMs; pCh0.Value sample.Channel0; pCh1.Value sample.Channel1; pCh2.Value sample.Channel2; pStatus.Value sample.Status; cmd.ExecuteNonQuery(); } tx.Commit(); }注意循环里不要重复调用cmd.Parameters.Clear()或者每次都新建 Command那会让事务的性能优势大打折扣。我实测过每次开启新命令插入一万条数据可能要好几秒用上面这种方式一万条基本在几十毫秒到一两百毫秒差距非常明显。5.3 实时内存缓冲 定时落盘内存层部分我用一个容量固定的环形缓冲来保存原始数据。实现不复杂关键是控制临界区避免采集线程和落盘线程互相干扰public class RingBufferT { private readonly T[] _buffer; private readonly object _lock new object(); private int _head; private int _count; public RingBuffer(int capacity) { _buffer new T[capacity]; } public bool TryAdd(T item) { lock (_lock) { int index (_head _count) % _buffer.Length; _buffer[index] item; if (_count _buffer.Length) { // 队列已满时覆盖最旧数据 _head (_head 1) % _buffer.Length; } else { _count; } return true; } } public ListT TakeAll() { lock (_lock) { var result new ListT(_count); while (_count 0) { int index _head; result.Add(_buffer[index]); _head (_head 1) % _buffer.Length; _count--; } return result; } } }后台落盘线程用Task.Run定期把内存缓冲的数据取走批量写入 SQLite。核心思路是“攒一批、写一次”既控制磁盘写频次又把采集延迟降到最低。public class PersistenceWorker { private readonly RingBufferSampleData _buffer; private readonly SqliteStore _store; private readonly CancellationToken _ct; public PersistenceWorker(RingBufferSampleData buffer, SqliteStore store, CancellationToken ct) { _buffer buffer; _store store; _ct ct; } public async Task RunAsync() { while (!_ct.IsCancellationRequested) { await Task.Delay(500, _ct).ConfigureAwait(false); var batch _buffer.TakeAll(); if (batch.Count 0) { try { _store.WriteSamples(batch); } catch (Exception ex) { // 记录异常把数据重新放回缓冲或者单独写入异常文件 Debug.WriteLine($Write failed: {ex.Message}); } } } // 退出前把剩余数据刷一遍 var rest _buffer.TakeAll(); if (rest.Count 0) { _store.WriteSamples(rest); } } }一个小细节落盘线程从缓冲里把数据取走后内存里就没有这些数据了。如果软件在写入 SQLite 之前崩溃这批数据就丢了。所以我一般在程序退出时做一次强制 flush同时把落盘周期控制在 1 秒以内即使偶尔丢数据也只会丢失最近一秒的数据对大多数设备监控场景来说是可以接受的。5.4 读取历史曲线防 UI 卡顿的一次性查询历史曲线回放时SQLite 的查询压力集中在“按时间段取大量数据”。如果一次性把整个时间窗口的数据全部加载到 UI 线程界面必然卡顿。我通常用异步查询加分段加载的方式第一次只查询总点数和首尾时间然后按缩放级别分批取数据。public async TaskListSampleData QueryRangeAsync(long startMs, long endMs, int limit) { await using var conn new SqliteConnection(_connectionString); await conn.OpenAsync(); using var cmd conn.CreateCommand(); cmd.CommandText SELECT ts, ch0, ch1, ch2, status FROM samples WHERE ts $start AND ts $end ORDER BY ts LIMIT $limit; ; cmd.Parameters.AddWithValue($start, startMs); cmd.Parameters.AddWithValue($end, endMs); cmd.Parameters.AddWithValue($limit, limit); var result new ListSampleData(); await using var reader await cmd.ExecuteReaderAsync(); while (await reader.ReadAsync()) { result.Add(new SampleData { TimestampMs reader.GetInt64(0), Channel0 reader.GetFloat(1), Channel1 reader.GetFloat(2), Channel2 reader.GetFloat(3), Status reader.GetInt32(4) }); } return result; }这里LIMIT不是单纯限制“最多取多少条”而是在查询策略上配合降采样如果时间窗口很大就直接查询一个降采样后的统计值比如每 10 秒一个平均/最大值。这种“先粗后细”的查询方式能让历史曲线在绝大多数机器上都能流畅回放。6. 常见问题与排查技巧实录6.1 database is locked 到底是谁的锅我相信不少人都被 SQLite 的“database is locked”折磨过。排查思路强烈建议按顺序来先确认是不是没开 WAL再确认是不是连接串没有启用连接池接着看代码里有没有长时间占用事务、有没有忘记了Dispose的 DataReader最后再检查是不是有第三方工具在用独占模式打开数据库文件。我之前遇到过一个很隐蔽的问题程序里有一个定时任务在后台统计一天的报警数查询语句写得特别慢扫了全表几百万行记录。每次这个统计任务执行时大批量写入就会被阻塞表现为采集线程那边的 INSERT 报锁错误。后来把统计查询加上索引并改成只扫最近一天的数据问题直接消失。所以“锁库”很多时候不是 SQLite 的并发能力不行而是你后台有一个慢查询把锁持有时间拉长了。6.2 C# 调用原生库时的 Access Violation别只怪三方库做上位机的人经常会调用各种 C DLL 或者采集卡的 SDK。搜索词里有个非常经典的问题C# 调用 C 时出现Access Violation c0000005。这个报错几乎都是内存访问越界或者函数调用约定不一致导致的和 SQLite 本身不大相关但如果你用微软官方封装之外的旧版 SQLite 库也可能因为 C 版本不匹配、指针生命周期管理不当在 GC 回收后触发类似崩溃。我自己的处理原则是能用官方托管库就用官方托管库Microsoft.Data.Sqlite内部对 SQLite 原生库做好了封装避免手写 DllImport 时踩内存坑。如果必须通过 P/Invoke 调用第三方 C 库一定要在调用处固定好缓冲区用Marshal.AllocHGlobal分配原生内存并在 finally 中释放千万不要把托管数组直接交给在后台线程运行的原生函数而不做固定。6.3 写入变慢时先看是不是事务粒度太小很多“SQLite 越用越慢”的报告最后查下来都是一个原因每一条数据都单独开一个事务提交。事务本身有开销每条都提交等于把每一条写入都放大成一次磁盘同步自然慢得离谱。解决方式非常直接用批量提交把 500ms 到 1 秒内攒下的数据放同一个事务。事务提交间隔也不能调到太久否则内存缓冲会堆积很多数据程序异常退出时的丢失窗口变大。我一般以 1 秒为上限如果一秒攒的数据超过五千条就缩短间隔到 500ms保证单次事务条数在一个合理范围。6.4 时间戳乱序导致曲线错乱还有一个经常被忽视的问题采集线程和落盘线程时间戳生成方式不统一。有的数据用采集时的时间有的数据用落盘时的时间结果就是历史曲线回放时出现时间倒流或者乱序。统一策略很重要。我建议所有数据在采集线程进入内存缓冲的那一刻就打好时间戳之后无论内存缓冲、落盘还是查询都不要再重新赋值。时间戳统一用DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()生成整数毫秒值避免本地时区、夏令时这类问题影响排序。6.5 数据库文件加密与备份的小技巧有人问 SQLite 数据库文件能否加密。答案是官方标准版不带加密需要走 SEESQLite Encryption Extension或者社区方案。但加密这种事在上位机项目里要慎重因为你要连同打开文件的程序一起考虑。如果只是怕客户把数据库文件拷走查看不如用轻量级的整体目录加密或者把数据库放在程序数据目录并通过访问控制限制权限实测成本更低。备份方面我推荐程序定期执行一次“全量复制”在程序空闲时段把主数据库文件复制到备份目录保留最近三份。WAL 模式下直接复制主库文件并不完整稳妥的做法是执行一次PRAGMA wal_checkpoint(TRUNCATE);让 WAL 文件合并回主库再复制主库文件。7. 最后分享一点项目经验在我做过的上位机项目里数据持久化这块踩的坑不算少但总结下来其实就是“分层、批量化、留备份”。不管是 SQLite 还是实时内存数据库都不需要追求极致的性能参数而要把重心放在“数据流是否顺畅”“故障时能不能恢复”“查询时用户是否觉得卡”这三件实际的事情上。如果新项目让我从零开始设计我会先把数据分类和时间戳规范定死再画数据流图确认各层职责然后才动手写代码。SQLite 作为历史存储层非常可靠进程内内存缓冲作为实时处理层非常高效两者组合起来能撑住绝大多数工业现场的数据需求。真到数据量爆炸的时候再把内存层换成独立时序数据库SQLite 层改成归档服务路是通的。最后一个小建议任何数据持久化方案都要在项目早期就做一次连续写入的压测让设备跑两三个小时观察数据库文件大小、写入延迟、内存占用和 CPU 占用。早期发现问题改代码永远比产品上线之后在现场救火要轻松得多。