1. 為什么上位機項目繞不開數(shù)據(jù)持久化——先看清你的數(shù)據(jù)模型做上位機開發(fā)的人大多經(jīng)歷過這種場面PLC、板卡或者儀器儀表傳回來的數(shù)據(jù)在界面上跑得飛快曲線、數(shù)字、開關量全部正常但只要一斷電或者軟件重啟歷史數(shù)據(jù)就全部蒸發(fā)?？蛻趄炇諘r隨口一句“我想看看上周那臺設備某幾個小時的曲線”你就得當場想辦法撈數(shù)據(jù)撈不出來就是事故。反過來我也見過不少新入行的同事覺得“數(shù)據(jù)持久化嘛不就是把每條數(shù)據(jù)往數(shù)據(jù)庫里懟”。于是采集線程里每來一條就執(zhí)行一次 INSERT結(jié)果界面卡死、數(shù)據(jù)庫文件膨脹、程序越跑越慢。問題不在于 SQLite 本身行不行而在于沒有想清楚“什么數(shù)據(jù)、什么頻率、存多久、誰來讀”這四件事。1.1 上位機里的三類數(shù)據(jù)性格完全不同我在實際項目里習慣把上位機的數(shù)據(jù)分成三類高速采集類數(shù)據(jù)典型是振動波形、電流瞬態(tài)值、位置誤差、編碼器反饋。這類數(shù)據(jù)采樣率從 100Hz 到幾十 kHz 都很常見每條數(shù)據(jù)可能只有幾個到幾十個字節(jié)但一秒鐘就能產(chǎn)生幾千到幾萬條記錄。這類數(shù)據(jù)如果直接落盤磁盤 IO 很快就成為瓶頸更麻煩的是它們通常用于實時曲線顯示和報警判斷寫磁盤的速度根本跟不上采集節(jié)奏。狀態(tài)與報警類數(shù)據(jù)比如設備啟停信號、故障碼、溫控開關動作、操作記錄。這類數(shù)據(jù)頻率低、每秒幾條甚至每分鐘幾條但價值高、需要長期保留、經(jīng)常會被檢索。客戶問“昨天凌晨三點那臺設備為什么停機”時查的就是這類數(shù)據(jù)。配置與工藝參數(shù)類數(shù)據(jù)比如配方、PID 參數(shù)、坐標補償值、設備型號。這類數(shù)據(jù)量小、改動不頻繁但是絕對不能丟。如果程序重啟后參數(shù)丟失整個設備都可能變成“工廠門禁都打不開”的狀態(tài)。這三類數(shù)據(jù)的訪問模式完全不同選型時如果用一套方案硬套要么過度設計要么性能翻車。我見過有人為了讓 10kHz 的波形數(shù)據(jù)實時展示硬是往 SQLite 里高頻寫結(jié)果數(shù)據(jù)庫還沒崩UI 先卡死了也有人因為省事把所有參數(shù)都扔在一個 CSV 文件里結(jié)果設備運行久了文件幾個 G打開都費勁。1.2 持久化發(fā)生在采集閉環(huán)的哪個位置上位機從硬件取數(shù)到界面展示中間至少經(jīng)過采集、解析、處理、顯示、存儲幾個環(huán)節(jié)。持久化不應該僅僅放在采集線程里面搞“實時同步寫”而應該把它視為整條數(shù)據(jù)處理鏈路上的一層。我通常建議畫一張簡單的數(shù)據(jù)流圖硬件設備 - 采集線程 - 原始數(shù)據(jù)緩存 - 實時計算/曲線顯示 - 存儲層。采集線程只負責把數(shù)據(jù)丟進緩存區(qū)顯示模塊從緩存區(qū)讀數(shù)據(jù)做實時渲染存儲層則按照設定策略把緩存區(qū)里的數(shù)據(jù)批量寫入歸檔。這樣無論是 SQLite 還是內(nèi)存數(shù)據(jù)庫都只是一個“后端角色”不會反向拖累前端采集。其實很多所謂“選型困難”根源在于沒有給每種數(shù)據(jù)分配不同的車道。高頻數(shù)據(jù)走內(nèi)存緩沖低頻記錄直接寫庫配置參數(shù)用單獨的表管理并定期備份這就是最樸素的分層思路。下面我把 SQLite 和實時內(nèi)存數(shù)據(jù)庫分別拆開講再給出組合用法。2. SQLite 在上位機里的定位與四個關鍵配置2.1 單機嵌入式數(shù)據(jù)庫的“部署友好”壓倒一切接觸過工控現(xiàn)場的人都知道客戶那臺工控機上的軟件環(huán)境有多“原生態(tài)”。有的機器連 VC 運行庫都沒裝全更別提 MySQL、PostgreSQL 那套獨立服務。上位機軟件要是在部署環(huán)節(jié)還得裝一個數(shù)據(jù)庫服務端項目經(jīng)理的臉當場就能拉下來。SQLite 最大的優(yōu)勢是它沒有服務端數(shù)據(jù)庫就是軟件目錄下的一個文件。C# 里用 Microsoft.Data.Sqlite 這個官方庫發(fā)布時帶上運行時需要的原生二進制客戶機器上只要能跑 .NET數(shù)據(jù)庫就能用。升級、備份、遷移都極其簡單關掉程序、復制文件、完事。這一點在工控場景里是實打?qū)嵉摹懊饩S護”。有些同事會說“我用 CSV 不也一樣嗎不就是寫文件嗎”。數(shù)據(jù)量小的時候是差不多但一旦涉及按時間段查詢、條件過濾、跨天統(tǒng)計CSV 的處理就非常痛苦。SQLite 至少給了你標準 SQL、索引、事務和并發(fā)控制哪怕你只用到其中兩成功能收益也已經(jīng)明顯超出文件方案。2.2 讓 SQLite 別卡脖子WAL、busy_timeout、synchronous、連接池不少人第一次用 SQLite 時被“database is locked”坑過然后就直接給 SQLite 判了死刑。其實這個錯誤大多數(shù)情況下不是 SQLite 不行而是你把滾珠軸承當錘子使。SQLite 默認的 rollback journal 模式下讀和寫會互相阻塞寫入時甚至可能阻塞整個數(shù)據(jù)庫文件的讀取。解決這個問題最常用的手段是開啟 WAL 模式也就是 Write-Ahead Logging。開啟之后寫入先落到一個獨立的-wal文件讀操作依然可以從主庫文件讀取讀寫并行能力大幅提升。我在代碼里一般這樣設置using var cmd conn.CreateCommand(); cmd.CommandText PRAGMA journal_modeWAL;; var mode cmd.ExecuteScalar()?.ToString(); // 正常返回值應當是 wal注意要檢查返回值如果返回的不是wal說明當前環(huán)境下寫入可能被限制或者數(shù)據(jù)庫處于其他狀態(tài)。WAL 模式啟用后你會在數(shù)據(jù)庫文件旁邊看到.wal和.shm兩個輔助文件這都是正常的程序正常關閉并 checkpoint 后會合并回主庫文件。第二個關鍵配置是busy_timeout。這個參數(shù)的作用是當數(shù)據(jù)庫文件被其他連接鎖住時當前操作最長等多久再報錯。我一般設置為 3000ms寫入線程爭取任務時如果遇到短時占用會自動等待而不是立刻拋出SQLITE_BUSY異常using var cmd conn.CreateCommand(); cmd.CommandText PRAGMA busy_timeout3000;; cmd.ExecuteNonQuery();第三個參數(shù)是synchronous。默認是 FULL每一次寫操作都要等待數(shù)據(jù)落盤安全但速度偏慢。數(shù)據(jù)量大的批量寫入場景我會在事務里臨時設置為 NORMAL。NORMAL 模式下 WAL 機制本身仍能保證數(shù)據(jù)庫崩潰時數(shù)據(jù)不會損壞只是極端掉電場景下可能丟失最近一小段已提交數(shù)據(jù)。對于絕大多數(shù)工業(yè)數(shù)據(jù)歸檔來說這個代價可以接受。第四個要點是連接串。很多人寫 SQLite 代碼喜歡每次操作都新建一個連接用完就關這在數(shù)據(jù)量大的時候非常浪費。Microsoft.Data.Sqlite 支持連接池要在連接串里顯式開啟var connStr new SqliteConnectionStringBuilder { DataSource dbPath, Mode SqliteOpenMode.ReadWriteCreate, Cache SqliteCacheMode.Shared, Pooling true }.ToString();連接池加上共享緩存能讓并發(fā)讀寫場景下的鎖沖突明顯減少。但也要注意連接池里的物理連接如果長時間空閑WAL 文件可能不會被及時 checkpoint所以長時間運行的程序最好定期執(zhí)行一下PRAGMA wal_checkpoint(TRUNCATE);或者干脆讓程序重啟時自動 checkpoint。2.3 數(shù)據(jù)庫文件損壞與恢復別指望每次都靠備份工業(yè)現(xiàn)場斷電從來不講道理Windows 異常關機、工控機藍屏、USB 被拔都有可能發(fā)生。SQLite 雖然有事務保護但也不能 100% 免疫文件損壞。我處理過的案例里最常見的是.wal文件異常殘留導致主庫打不開或者是數(shù)據(jù)庫文件被第三方工具半路打開改壞了。遇到這種問題我一般先從備份恢復所以我的程序里會保留最近三份數(shù)據(jù)庫備份文件這是最后一道防線。如果連備份都沒有也先別急著刪除文件可以試試 SQLite 自帶的恢復機制。使用 Db Browser for SQLite 時File - Export - Export to SQL file有時能把還能讀出來的數(shù)據(jù)轉(zhuǎn)成 SQL 腳本再用腳本重建數(shù)據(jù)庫。命令行里可以用.recover命令但這兩招的成功率取決于文件損壞程度別抱太大希望。2.4 一個順手的小工具Db Browser for SQLite排查 SQLite 數(shù)據(jù)問題純靠寫代碼看結(jié)果太慢了。我調(diào)試時基本都會開著 Db Browser for SQLite直接打開數(shù)據(jù)庫文件查看表結(jié)構、索引和數(shù)據(jù)內(nèi)容。它還支持執(zhí)行任意 SQL方便我驗證查詢語句的寫法。比如我要確認某張表的數(shù)據(jù)量、檢查時間字段是否被正確存儲、查看高頻寫入后 WAL 文件有沒有異常膨脹直接用這個工具跑一條SELECT count(*) FROM samples WHERE ts ...就清楚了。還有一個很實用的功能是“Define Query”可以用它快速寫一條帶參數(shù)的查詢語句調(diào)試復雜統(tǒng)計邏輯時省不少事。3. 實時內(nèi)存數(shù)據(jù)庫高頻采集場景的“緩沖層”3.1 不是每個項目都需要一個真正的“內(nèi)存數(shù)據(jù)庫”名詞聊到實時內(nèi)存數(shù)據(jù)庫很多人第一反應是 Redis、Memcached 這類獨立服務。但在上位機項目里情況往往沒有這么“重型”。工控現(xiàn)場就一臺工控機客戶不會同意你為了存數(shù)據(jù)再部署一個 Redis 服務更不會維護它。所以我在大多數(shù)項目里說的“實時內(nèi)存數(shù)據(jù)庫”其實指的是進程內(nèi)維護的一套內(nèi)存數(shù)據(jù)機構加上必要的并發(fā)控制和查詢接口。它要解決的核心問題是高頻數(shù)據(jù)進入系統(tǒng)后既要讓顯示模塊毫秒級拿到數(shù)據(jù)又不能因為等磁盤 IO 拖慢采集。簡單的ListSample不夠用因為讀寫競爭會帶來臟數(shù)據(jù)不加容量上限也不行進程跑一晚上會把內(nèi)存吃光。所以一個合格的上位機內(nèi)存數(shù)據(jù)層應該具備這幾點無鎖或輕量鎖的并發(fā)讀寫、容量上限或過期淘汰機制、按時間窗口快速查詢的能力。舉個例子我的一個項目里32 個通道每 10ms 采集一條原始數(shù)據(jù)也就是每秒 3200 條記錄。實時顯示只需要最近 500 條點但整段曲線的原始數(shù)據(jù)可能要持續(xù)采集幾個小時。如果把這些數(shù)據(jù)全部塞進內(nèi)存假設每條記錄包含時間戳和 32 個 float 和一個狀態(tài)字節(jié)算下來約 140 字節(jié)一小時就是 50 萬條占內(nèi)存約 70MB還可以接受。但如果連續(xù)采集一天就是 1.7GB 內(nèi)存這在工控機上已經(jīng)不便宜了。3.2 輕量級內(nèi)存數(shù)據(jù)庫設計環(huán)形緩沖加時間窗口我的習慣是給高頻采集數(shù)據(jù)做一個“容量有限、后續(xù)有機會落盤”的緩沖層。最常用的是環(huán)形緩沖容量固定新數(shù)據(jù)到來時如果緩沖滿了最老的記錄會被覆蓋。這樣內(nèi)存占用永遠有上限實時曲線永遠能拿到最近的數(shù)據(jù)而落盤由另一個線程從緩沖里批量取走并寫入 SQLite。還有一個更輕量的選擇是直接用ConcurrentQueueT不需要自己實現(xiàn)鎖。它的優(yōu)勢是 FIFO 語義非常自然缺點是沒有容量上限要你自己在入隊時檢查Count并且手動丟棄隊尾元素。實測下來采集線程入隊、后臺線程出隊寫庫、主線程偶爾查最近數(shù)據(jù)這個組合在上位機場景里很穩(wěn)。真正需要“數(shù)據(jù)庫”語義的時候也就是要按時間范圍查某個通道的值、要做聚合計算、要根據(jù)報警條件做復雜篩選時一個沒有索引的容器就不夠了。這時候我建議直接用時間序列的專用思路數(shù)據(jù)在內(nèi)存中按通道分片每個分片內(nèi)部是一個按時間排序的數(shù)組再保存一份分片的時間范圍索引。查詢時先定位到分片再做二分查找。這個實現(xiàn)并不復雜但性能比掃描全量列表高一個數(shù)量級。3.3 什么時候可以直接引入外部時序數(shù)據(jù)庫如果項目本身就是一個數(shù)據(jù)密集型平臺采集點很多、讀取方也不只一個上位機那內(nèi)部的“內(nèi)存數(shù)據(jù)容器”確實不夠用了。這種情況下可以選擇正式的內(nèi)存數(shù)據(jù)庫或時序數(shù)據(jù)庫。常見的有 Redis 搭配 Stream 數(shù)據(jù)類型處理時間序列也有 InfluxDB、QuestDB 這類專門為時序場景設計的存儲。但我要提醒一句引入外部服務意味著你的項目從“單機軟件”變成了“分布式系統(tǒng)”。權限管理、網(wǎng)絡連接、客戶端依賴、服務自動拉起、現(xiàn)場機器資源占用這些都要評估。上位機項目多數(shù)時候跑在 Windows 工控機上現(xiàn)場沒有專職運維我不建議一上來就用重方案。先用進程內(nèi)緩沖加 SQLite 扛住等數(shù)據(jù)量確實大到單機撐不住再考慮橫向拆分這條路最穩(wěn)。4. 選型對比持續(xù)寫入的持久層到底怎么決策4.1 一張表看清 SQLite 和實時內(nèi)存數(shù)據(jù)庫的差異很多朋友糾結(jié)“SQLite 和內(nèi)存數(shù)據(jù)庫哪個好”其實答案取決于你拿它做什么場景。我整理了一張對比表基本覆蓋了大多數(shù)上位機項目的考量點對比維度SQLite進程內(nèi)實時內(nèi)存數(shù)據(jù)庫數(shù)據(jù)生命周期永久保存重啟不丟臨時保存重啟即丟寫入頻率上限受磁盤 IO 和 WAL 影響一般每秒幾千次批量寫入沒問題但不宜單條高頻寫微秒級可達每秒幾十萬次以上查詢能力標準 SQL、索引、聚合、條件篩選都非常方便需要自己實現(xiàn)索引或按時間窗口掃描并發(fā)模型多連接需要 WAL 和 busy_timeout 配合單寫多讀最穩(wěn)進程內(nèi)共享內(nèi)存用鎖或無鎖結(jié)構維護部署復雜度單文件無服務端發(fā)布簡單無外部部署隨程序啟動可靠性事務機制掉電后較易恢復掉電丟數(shù)需要定期落盤兜底典型用途歷史歸檔、報警記錄、配置參數(shù)、報表查詢實時曲線、高速采樣緩沖、報警判斷的臨時數(shù)據(jù)集這張表其實已經(jīng)暗示了一個結(jié)論這兩者根本不是競爭關系而是接力關系。4.2 按寫入頻次和數(shù)據(jù)語義畫一條決策線我在做選型時習慣先回答三個問題數(shù)據(jù)到達頻次是多少如果每條數(shù)據(jù)間隔大于 100ms、每秒寫入不超過幾十條SQLite 完全可以直接寫入不需要額外的內(nèi)存緩沖。如果每秒幾百條到幾千條建議用內(nèi)存緩沖積累一段時間再批量向 SQLite 落盤。如果每秒上萬條甚至更高你要考慮是不是真的需要全部原始數(shù)據(jù)落盤還是只保留統(tǒng)計特征值就夠了。數(shù)據(jù)需要保存多久、誰來讀歸檔數(shù)據(jù)肯定要長期保存那就必須落到 SQLite 或者其他真持久化存儲中。內(nèi)存數(shù)據(jù)庫里的數(shù)據(jù)只能作為臨時態(tài)不能指望它撐起客戶“查前三個月數(shù)據(jù)”的需求。數(shù)據(jù)是否需要跨進程共享上位機如果只有一個進程進程內(nèi)緩沖完全夠用。如果有多個上位機同時讀同一批數(shù)據(jù)比如中控室和現(xiàn)場同時看一臺設備就需要考慮真正的服務端存儲。4.3 兩層并用才是大多數(shù)項目的最終答案選 SQLite 和內(nèi)存數(shù)據(jù)庫從來不是“二選一”。我經(jīng)手的項目里最終落地的方案基本都是兩層內(nèi)存層負責承接高頻采集數(shù)據(jù)按時間窗口保存最近幾分鐘到幾小時的數(shù)據(jù)用于實時曲線和報警判斷SQLite 層負責把內(nèi)存層的數(shù)據(jù)批量落盤用于歷史查詢、報表導出和故障追溯。典型流程是采集線程把數(shù)據(jù)寫入內(nèi)存緩沖后臺落盤線程每隔一秒或幾百毫秒從內(nèi)存緩沖里取一批數(shù)據(jù)放進一個臨時列表然后開啟事務批量插入 SQLite。這樣 SQLite 的寫入頻率大大降低每條 SQL 都能處理成百上千條記錄效率和數(shù)據(jù)安全性都得到保障。同時內(nèi)存層因為容量受限內(nèi)存占用始終可控即使出現(xiàn)極端情況也只是丟了最近一小段來不及落盤的數(shù)據(jù)不會導致整個程序崩潰。這個架構看起來簡單但很多項目一開始沒做好問題往往出在沒有人明確劃分“哪些數(shù)據(jù)必須落盤、哪些數(shù)據(jù)只要內(nèi)存”。我自己的原則是設備配置、報警事件、統(tǒng)計結(jié)果必須落盤原始波形按采樣率評估能落盤就落盤不能落盤就保存特征值中間計算過程只放內(nèi)存不用考慮持久化。5. 實戰(zhàn)一套采集、緩存、落盤的參考實現(xiàn)5.1 一個真實項目參數(shù)我在一個自動化檢測項目里處理過這樣一臺設備上位機通過串口和采集卡讀取 32 通道的數(shù)據(jù)采樣周期 10ms也就是每秒產(chǎn)生 3200 條記錄。每條記錄包含時間戳、32 個浮點通道值和一個狀態(tài)碼序列化后大概 140 字節(jié)。需求是實時曲線展示最近 30 秒的數(shù)據(jù)歷史數(shù)據(jù)至少保留 30 天期間任何時間段都要能回放曲線程序異常退出或斷電后已經(jīng)采集的重要數(shù)據(jù)盡量不丟。這個需求下內(nèi)存數(shù)據(jù)庫和 SQLite 必須配合單靠任何一邊都搞不定。5.2 數(shù)據(jù)庫表設計與批量寫入SQLite 部分我建的表結(jié)構大概長這樣CREATE TABLE IF NOT EXISTS samples ( id INTEGER PRIMARY KEY AUTOINCREMENT, ts INTEGER NOT NULL, ch0 REAL, ch1 REAL, ch2 REAL, -- 按實際通道數(shù)擴展 status INTEGER ); CREATE INDEX IF NOT EXISTS idx_samples_ts ON samples(ts);時間戳用 Unix 毫秒整數(shù)存儲。不要用字符串時間或者默認的 ISO8601 文本格式字符串查詢和排序性能都差一大截尤其在數(shù)據(jù)量上來之后。寫入時不要把單條 INSERT 暴露給采集線程整理成一個批量寫入方法。下面的代碼用 Microsoft.Data.Sqlite 實現(xiàn)核心是“一個事務、一條命令、循環(huán)復用參數(shù)”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(); }注意循環(huán)里不要重復調(diào)用cmd.Parameters.Clear()或者每次都新建 Command那會讓事務的性能優(yōu)勢大打折扣。我實測過每次開啟新命令插入一萬條數(shù)據(jù)可能要好幾秒用上面這種方式一萬條基本在幾十毫秒到一兩百毫秒差距非常明顯。5.3 實時內(nèi)存緩沖 定時落盤內(nèi)存層部分我用一個容量固定的環(huán)形緩沖來保存原始數(shù)據(jù)。實現(xiàn)不復雜關鍵是控制臨界區(qū)避免采集線程和落盤線程互相干擾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) { // 隊列已滿時覆蓋最舊數(shù)據(jù) _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定期把內(nèi)存緩沖的數(shù)據(jù)取走批量寫入 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) { // 記錄異常把數(shù)據(jù)重新放回緩沖或者單獨寫入異常文件 Debug.WriteLine($Write failed: {ex.Message}); } } } // 退出前把剩余數(shù)據(jù)刷一遍 var rest _buffer.TakeAll(); if (rest.Count 0) { _store.WriteSamples(rest); } } }一個小細節(jié)落盤線程從緩沖里把數(shù)據(jù)取走后內(nèi)存里就沒有這些數(shù)據(jù)了。如果軟件在寫入 SQLite 之前崩潰這批數(shù)據(jù)就丟了。所以我一般在程序退出時做一次強制 flush同時把落盤周期控制在 1 秒以內(nèi)即使偶爾丟數(shù)據(jù)也只會丟失最近一秒的數(shù)據(jù)對大多數(shù)設備監(jiān)控場景來說是可以接受的。5.4 讀取歷史曲線防 UI 卡頓的一次性查詢歷史曲線回放時SQLite 的查詢壓力集中在“按時間段取大量數(shù)據(jù)”。如果一次性把整個時間窗口的數(shù)據(jù)全部加載到 UI 線程界面必然卡頓。我通常用異步查詢加分段加載的方式第一次只查詢總點數(shù)和首尾時間然后按縮放級別分批取數(shù)據(jù)。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不是單純限制“最多取多少條”而是在查詢策略上配合降采樣如果時間窗口很大就直接查詢一個降采樣后的統(tǒng)計值比如每 10 秒一個平均/最大值。這種“先粗后細”的查詢方式能讓歷史曲線在絕大多數(shù)機器上都能流暢回放。6. 常見問題與排查技巧實錄6.1 database is locked 到底是誰的鍋我相信不少人都被 SQLite 的“database is locked”折磨過。排查思路強烈建議按順序來先確認是不是沒開 WAL再確認是不是連接串沒有啟用連接池接著看代碼里有沒有長時間占用事務、有沒有忘記了Dispose的 DataReader最后再檢查是不是有第三方工具在用獨占模式打開數(shù)據(jù)庫文件。我之前遇到過一個很隱蔽的問題程序里有一個定時任務在后臺統(tǒng)計一天的報警數(shù)查詢語句寫得特別慢掃了全表幾百萬行記錄。每次這個統(tǒng)計任務執(zhí)行時大批量寫入就會被阻塞表現(xiàn)為采集線程那邊的 INSERT 報鎖錯誤。后來把統(tǒng)計查詢加上索引并改成只掃最近一天的數(shù)據(jù)問題直接消失。所以“鎖庫”很多時候不是 SQLite 的并發(fā)能力不行而是你后臺有一個慢查詢把鎖持有時間拉長了。6.2 C# 調(diào)用原生庫時的 Access Violation別只怪三方庫做上位機的人經(jīng)常會調(diào)用各種 C DLL 或者采集卡的 SDK。搜索詞里有個非常經(jīng)典的問題C# 調(diào)用 C 時出現(xiàn)Access Violation c0000005。這個報錯幾乎都是內(nèi)存訪問越界或者函數(shù)調(diào)用約定不一致導致的和 SQLite 本身不大相關但如果你用微軟官方封裝之外的舊版 SQLite 庫也可能因為 C 版本不匹配、指針生命周期管理不當在 GC 回收后觸發(fā)類似崩潰。我自己的處理原則是能用官方托管庫就用官方托管庫Microsoft.Data.Sqlite內(nèi)部對 SQLite 原生庫做好了封裝避免手寫 DllImport 時踩內(nèi)存坑。如果必須通過 P/Invoke 調(diào)用第三方 C 庫一定要在調(diào)用處固定好緩沖區(qū)用Marshal.AllocHGlobal分配原生內(nèi)存并在 finally 中釋放千萬不要把托管數(shù)組直接交給在后臺線程運行的原生函數(shù)而不做固定。6.3 寫入變慢時先看是不是事務粒度太小很多“SQLite 越用越慢”的報告最后查下來都是一個原因每一條數(shù)據(jù)都單獨開一個事務提交。事務本身有開銷每條都提交等于把每一條寫入都放大成一次磁盤同步自然慢得離譜。解決方式非常直接用批量提交把 500ms 到 1 秒內(nèi)攢下的數(shù)據(jù)放同一個事務。事務提交間隔也不能調(diào)到太久否則內(nèi)存緩沖會堆積很多數(shù)據(jù)程序異常退出時的丟失窗口變大。我一般以 1 秒為上限如果一秒攢的數(shù)據(jù)超過五千條就縮短間隔到 500ms保證單次事務條數(shù)在一個合理范圍。6.4 時間戳亂序?qū)е虑€錯亂還有一個經(jīng)常被忽視的問題采集線程和落盤線程時間戳生成方式不統(tǒng)一。有的數(shù)據(jù)用采集時的時間有的數(shù)據(jù)用落盤時的時間結(jié)果就是歷史曲線回放時出現(xiàn)時間倒流或者亂序。統(tǒng)一策略很重要。我建議所有數(shù)據(jù)在采集線程進入內(nèi)存緩沖的那一刻就打好時間戳之后無論內(nèi)存緩沖、落盤還是查詢都不要再重新賦值。時間戳統(tǒng)一用DateTimeOffset.UtcNow.ToUnixTimeMilliseconds()生成整數(shù)毫秒值避免本地時區(qū)、夏令時這類問題影響排序。6.5 數(shù)據(jù)庫文件加密與備份的小技巧有人問 SQLite 數(shù)據(jù)庫文件能否加密。答案是官方標準版不帶加密需要走 SEESQLite Encryption Extension或者社區(qū)方案。但加密這種事在上位機項目里要慎重因為你要連同打開文件的程序一起考慮。如果只是怕客戶把數(shù)據(jù)庫文件拷走查看不如用輕量級的整體目錄加密或者把數(shù)據(jù)庫放在程序數(shù)據(jù)目錄并通過訪問控制限制權限實測成本更低。備份方面我推薦程序定期執(zhí)行一次“全量復制”在程序空閑時段把主數(shù)據(jù)庫文件復制到備份目錄保留最近三份。WAL 模式下直接復制主庫文件并不完整穩(wěn)妥的做法是執(zhí)行一次PRAGMA wal_checkpoint(TRUNCATE);讓 WAL 文件合并回主庫再復制主庫文件。7. 最后分享一點項目經(jīng)驗在我做過的上位機項目里數(shù)據(jù)持久化這塊踩的坑不算少但總結(jié)下來其實就是“分層、批量化、留備份”。不管是 SQLite 還是實時內(nèi)存數(shù)據(jù)庫都不需要追求極致的性能參數(shù)而要把重心放在“數(shù)據(jù)流是否順暢”“故障時能不能恢復”“查詢時用戶是否覺得卡”這三件實際的事情上。如果新項目讓我從零開始設計我會先把數(shù)據(jù)分類和時間戳規(guī)范定死再畫數(shù)據(jù)流圖確認各層職責然后才動手寫代碼。SQLite 作為歷史存儲層非?？煽窟M程內(nèi)內(nèi)存緩沖作為實時處理層非常高效兩者組合起來能撐住絕大多數(shù)工業(yè)現(xiàn)場的數(shù)據(jù)需求。真到數(shù)據(jù)量爆炸的時候再把內(nèi)存層換成獨立時序數(shù)據(jù)庫SQLite 層改成歸檔服務路是通的。最后一個小建議任何數(shù)據(jù)持久化方案都要在項目早期就做一次連續(xù)寫入的壓測讓設備跑兩三個小時觀察數(shù)據(jù)庫文件大小、寫入延遲、內(nèi)存占用和 CPU 占用。早期發(fā)現(xiàn)問題改代碼永遠比產(chǎn)品上線之后在現(xiàn)場救火要輕松得多。