SQLite 在工控现场跑了三年没出事稳态运维就靠这三板斧先说结论工控单机场景下SQLite 比 MySQL 省一个运维岗位但前提是把三件事做对——稳态参数、按月分表、备份与恢复演练。这三件事加起来不到一百行代码却决定了这个库是三年不闻不问还是半年写满一个盘、断电一次就打不开。下面把这三板斧逐个拆开所有命令和代码都能直接跑。一、先把稳态参数调对三条 PRAGMASQLite 默认配置是给手机 App 设计的工控 7×24 小时写入的场景要改三个参数连接建立后执行一次即可PRAGMA journal_modeWAL;-- 写前日志模式读写不互斥采集程序写、查询程序读互不卡PRAGMA synchronousNORMAL;-- WAL 模式下的推荐档断电最多丢最后一次事务不损坏库PRAGMA busy_timeout5000;-- 写锁冲突时等 5 秒再报错而不是立刻抛 database is locked三条各有讲究。WAL 是最重要的一条默认的回滚日志模式下写操作会阻塞读工控现场采集程序在写、看板程序在读是常态不开 WAL 就会周期性报database is locked。synchronous 不要设成 OFF那确实是写入最快但断电可能把库写坏——工控现场最不缺的就是断电。busy_timeout是给多进程访问兜底的5 秒足够大多数写事务完成。另外有一条纪律WAL 模式下拷贝数据库文件时必须连-wal和-shm文件一起拷或先wal_checkpoint再拷只拷主文件会丢最近未落盘的事务——这是备份脚本最常见的坑后面第三节会给出正确姿势。二、按月分表让写满一个盘永不发生单表无限增长的后果是三连文件几十 GB、查询越来越慢、备份越来越久。按月分表是最朴素的解法——写入时路由到当月表跨月自动建新表CREATETABLEIFNOTEXISTSrecords_2026_09(tsINTEGERNOTNULL,-- Unix 时间戳秒stationTEXTNOTNULL,-- 工位/设备标识payloadTEXTNOTNULL-- JSON 或紧凑字符串);CREATEINDEXIFNOTEXISTSidx_r_2026_09_tsONrecords_2026_09(ts);写入路由只要一个函数以 Python 为例importsqlite3,datetimedefconn_for_month(db_path,dt:datetime.datetime)-sqlite3.Connection:namefrecords_{dt:%Y_%m}csqlite3.connect(db_path,timeout5)c.execute(fCREATE TABLE IF NOT EXISTS{name}( ts INTEGER NOT NULL, station TEXT NOT NULL, payload TEXT NOT NULL))c.execute(fCREATE INDEX IF NOT EXISTS idx_{name}_ts ON{name}(ts))c.execute(PRAGMA busy_timeout 5000)returnc配套一个保留策略只留最近 N 个月超期的表整表归档打包成 zip 或转 CSV后 DROP。整表 DROP 是秒级的比DELETE FROM 单表 WHERE ts ...快几个数量级还不产生碎片——这是分表相对单表最大的运维红利。查询端如果确实要跨月用UNION ALL拼两个月表即可跨月报表是低频操作慢一点无妨别为它牺牲写入端的简洁。三、备份不停机VACUUM INTO 一行搞定网上大量教程还在教停程序再拷文件其实 SQLite 早有在线备份的正确姿势——VACUUM INTO单条 SQL不锁业务、顺手还能压缩碎片importsqlite3,time,osdefbackup_db(db:str,out_dir:str,keep:int14)-str:os.makedirs(out_dir,exist_okTrue)stamptime.strftime(%Y%m%d_%H%M)destos.path.join(out_dir,f{os.path.basename(db)}.{stamp}.bak)csqlite3.connect(db,timeout5)c.execute(VACUUM INTO ?,(dest,))# 在线备份不需要停写入c.close()# 只保留最近 keep 份bakssorted(fforfinos.listdir(out_dir)iff.endswith(.bak))foroldinbaks[:-keep]:os.remove(os.path.join(out_dir,old))returndest把它挂进 Windows 任务计划每天跑一次就得到了最近 14 天、每天一份、可秒级恢复的保险。备份文件记得定期拷一份到另一块盘或 NAS——备份和数据库在同一块盘上盘一坏全没。四、真损坏了怎么办三步恢复法就算参数全对强断电加上极端时序仍可能把库写坏症状通常是打开就报database disk image is malformed。三步走第一步体检确认损坏范围PRAGMA integrity_check;-- 返回 ok 则没坏返回错误行号则继续第二步第二步用 .recover 抢救数据SQLite 3.29 自带按页扫坏页跳过、好页全捞sqlite3 broken.db .recover | sqlite3 new.db第三步从最近的 .bak 备份补齐缺口.recover 抢出来的是事故时刻之前的数据拿备份文件做参照核对行数缺的区间从备份补。三层保险WAL 少丢、每日备份、.recover 兜底同时失效的概率比单盘损坏本身还低。我自己的做法是把这三步写成一页 A4 的《恢复手册》贴在现场机柜里——恢复这种事从来不是发生在你方便的时候能照着敲的文档比记忆可靠。五、把三件事交给定时任务人只看报警三板斧全部脚本化之后剩下的就是排班每日VACUUM INTO备份、每周 integrity_check 巡检、每月归档超期表。巡检结果写一行日志异常才发通知工控现场用邮件或企业微信机器人都行。人不需要记得这些事只需要在报警出现时出现。这套脚本化 定时跑 异常才叫人的运维思路再往前一步就是让 AI 帮你把巡检、归档、恢复这些活自动编排起来——《AI Agent 与自动化开发实战》里有从单脚本到智能体的完整打法12.9 元作者付费资源采集侧的数据从哪来也可以看我前面写的 Modbus 调试那篇。库的稳态没有玄学参数、分表、备份三件事做到位它就能安安静静跑很多年。SQLite 在工控现场跑了三年没出事稳态运维就靠这三板斧