单机上位机用什么数据库？
SQLite vs MySQL vs TDengine
💡 小项目要不要直接上 MySQL？SQLite 会不会锁库？TDengine 单机版够不够？20 年工控老兵的实战选型。
接《工业历史数据用什么存》那篇，这次聚焦最常见的场景——单机/小项目的上位机到底用哪个数据库。不堆理论，按你项目的真实规模对号入座：小工装检测台、产线追溯系统、高频测点趋势，三个场景三个答案。
单机小设备、离线单人用——SQLite 零部署最省心；要多用户、远程访问、业务追溯——上 MySQL；高频测点秒级写入、要趋势曲线——TDengine 单机版。正经数字化项目不要用一个库硬扛所有需求，SQLite 做本地缓存、MySQL 管业务、TDengine 存历史，三者组合才是正道。
01 先搞清楚：三个库到底各自擅长什么
很多人纠结选哪个库，是因为没先想清楚数据要存什么。工控现场的数据其实分三类：
- 业务数据（工单、配方、报警规则、用户权限）：会增删改、要关联查询、要事务——关系库的主场。
- 测点历史（温度、压力、转速随时间的值）：只追加、按时间查、写入量大——时序库的主场。
- 单机短期数据（缓存、日志、本地临时记录）：零部署、单文件、不对外——SQLite 的主场。
下面 10 个维度，把三个库放在一起比。
02 10 个维度逐项对比
| 对比维度 | SQLite | MySQL | TDengine |
|---|---|---|---|
| 部署复杂度 | 零部署，一个文件，拷过去就能用，无需安装服务 | 要装 MySQL 服务、配账号端口、开机自启，运维成本高 | 要装 TDengine 服务端，配置相对简单但仍需运维 |
| 并发能力 | 文件级锁，同时写会锁库；适合单进程上位机，多客户端并发写吃力 | 成熟的多用户并发，连接池、锁机制完善，多客户端同时写没问题 | 为高频并发写入设计，多采集端同时写很轻松 |
| 高频测点写入 | 每秒几十~几百行可以，再高要批量写；适合秒级、几十点 | 每秒几百~几千行，再高要分表批量插；适合业务数据+少量历史 | 单机 10 万+ 行/秒，为高频测点写入而生 |
| SQL 能力 | 完整 SQL，支持事务、JOIN、视图、触发器，语法和 MySQL 几乎一致 | 功能最全，存储过程、视图、复杂查询、主从复制都有 | 类 SQL，但不支持复杂 JOIN、事务、子查询，专做时序查询 |
| 跨平台/嵌入式 | 单文件跨 Windows/Linux/嵌入式，无架构依赖，工控机直接跑 | 要装服务端，嵌入式 Linux 上跑 MySQL 偏重 | 有单机版可跑在工控机，但资源占用比 SQLite 大 |
| 远程/多客户端 | 文件在本机，远程访问要自己做 HTTP 接口或文件共享，不直接支持 | TCP 直连，多台电脑、远程、Web 后端都能连 | TCP 直连，Grafana、Web 后端、多客户端都能连 |
| 数据量上限 | 单库理论 140TB，实际建议单表千万行以内；上亿行查询变慢 | 单表千万~亿行，分表后可到十亿级；适合业务数据 | 单机可处理亿级测点数据，列式压缩后磁盘极小 |
| 备份维护 | 复制文件即备份，零维护；要注意 WAL 模式和定期 VACUUM | 要 mysqldump 或定时备份，要监控磁盘、慢查询、优化表 | 自动过期、自动归档，运维最省心 |
| 生态/工具 | DB Browser for SQLite 免费可视化，Navicat/DBeaver 都支持 | 生态最全，Navicat、DBeaver、PHPMyAdmin、ORM 框架都支持 | TDengine Explorer 可视化，Grafana 原生支持 |
| 授权成本 | 公有领域，完全免费，可闭源商用 | GPL，商用要注意；MySQL Community 免费但闭源产品分发要授权 | 社区版 AGPL，闭源商用要评估授权；单机小项目可免费 |
03 按项目场景对号入座
| 项目类型 | 特点 | 关键诉求 | 数据规模 | 磁盘占用 | 建议路线 |
|---|---|---|---|---|---|
| 单机小设备 / 检测台 | ≤ 50 点 | 秒级~5秒 | 1 个文件搞定 | < 1 GB/年 | SQLite |
| 单机产线 + 业务 | 追溯/报表/工单 | 要多用户、要远程 | 中等数据量 | MySQL 几 GB | MySQL |
| 高频测点 + 趋势 | 100~2000 点 | 秒级写入 | 亿级行/年 | TDengine 压缩后极小 | TDengine |
| 正经数字化项目 | 业务+历史都要 | 多客户端、远程 | 多库配合 | SQLite 本地 + MySQL 业务 + TDengine 历史 | 三库组合 |
04 三种决策，帮你拍板
- 单机设备、检测台、小型工装
- 离线运行、单人单进程用
- 点位几十、秒级采样
- 要零部署、零维护、客户工控机上不装额外服务
- 预算紧，不想为数据库付任何成本
- 要多用户、多客户端同时访问
- 有工单、配方、报表等业务数据
- 要远程连接、Web 后端对接
- 数据量千万级、要复杂 SQL 查询
- 团队熟 MySQL，运维有保障
- 测点上百、秒级高频写入
- 要画趋势曲线、做降采样聚合
- 要存多年历史、自动过期归档
- 磁盘敏感，要高压缩比
- 要 Grafana 做可视化看板
05 丁丁的实战建议
第一，别用一个库硬扛所有需求。这是新手最常犯的错——上来就上 MySQL，然后把所有测点历史也塞进去，几个月后查询慢、磁盘爆。正确做法是按数据类型分工：业务数据给关系库，测点历史给时序库。
第二，小项目别过度设计。单机检测台用 SQLite，一个文件拷过去就能跑，客户工控机上不用装任何数据库服务，出问题把文件拷回来就能查。这比上 MySQL 省下来的运维时间，远比"以后要迁移"的顾虑值钱。
第三，迁移成本很低，别一开始就背上。SQLite 和 MySQL 的 SQL 语法几乎一致，等真的需要多用户远程访问了，导出数据导入 MySQL 就行，ORM 层改个连接字符串的事。不要为了"万一以后要扩展"，在小项目里背上 MySQL 的运维成本。
常见问题 FAQ（选型时最常被问）
Q：SQLite 到底能不能做上位机数据库？
A：完全可以，而且是单机小项目的最佳选择。它就是一个文件、零部署、免维护、免费可商用。我做单机检测设备、小型工装的历史数据和业务记录，首选 SQLite。但要记住它的边界：单进程上位机用没问题，一旦要多台电脑同时写、要远程直连、要存亿级测点历史，就该升级到 MySQL 或 TDengine。
Q：SQLite 会不会并发写锁库？
A：会，这是它最容易踩的坑。SQLite 是文件级锁，同一时刻只能一个写进程。单进程上位机内部写、查询不冲突（开 WAL 模式即可）；但如果多客户端（比如上位机 + Web 后端 + 另一个程序）同时写同一个 SQLite 文件，就会锁库报错。WAL 模式能缓解读写并发，但写并发本质上还是串行。多客户端场景直接上 MySQL。
Q：单机项目要不要直接上 MySQL，省得以后迁移？
A：不建议，这是典型的过度设计。MySQL 要装服务、配账号、开机自启、做备份、监控磁盘，运维成本对单机小项目是负担。客户工控机上多一个 MySQL 服务，就多一个故障点。正确做法：单机小项目先用 SQLite，等真的需要多用户、远程访问、和 MES 打通了，再升级到 MySQL——SQLite 的 SQL 语法和 MySQL 几乎一致，迁移成本很低。
Q：TDengine 单机版够不够小项目用？
A：够，但要看场景。如果你的核心需求是"存测点历史、画趋势曲线、做降采样"，即使只有几百点，TDengine 单机版也比 MySQL/SQLite 合适——写入快、压缩比高、自动过期。但如果你的项目主要是工单、配方、报警主数据这类业务记录，TDengine 反而不合适（它不擅长事务和关联查询），那种场景用 SQLite 或 MySQL。
Q：三个库能不能一起用？
A：能，而且这是成熟工控系统的标准做法。SQLite 做本地缓存和单机短期数据；MySQL 存业务数据（用户、工单、配方、报警规则）；TDengine 存测点历史（趋势、曲线、降采样）。三者通过统一的数据访问接口对外提供服务，互不干扰。我现在的项目基本都是这个组合，而不是用一个库硬扛所有需求。
Q：SQLite 数据量大了怎么办？
A：三招：①开 WAL 模式，提升并发；②定期归档，把一年前的历史数据导出到独立的历史库文件，主库只留近期数据；③单表超千万行就考虑换库。SQLite 单表上千万行后查询会明显变慢，这时候不是优化 SQL 能解决的，该上时序库就上时序库。
Q：MySQL 能不能嵌入式部署到工控机，免安装？
A：原生 MySQL 不行，要装服务端。但有两个替代：①用 MariaDB 嵌入式版本（libmariadb），链接进程序里；②更简单的做法是用 SQLite，它本质就是嵌入式数据库。如果客户非要 MySQL 协议（比如已有远程工具连），可以用 MySQL Community 静默安装，但运维成本要算进去。
Q：客户要在手机/总部看数据，该选哪个库？
A：这种场景不要让手机直连数据库。标准做法：SQLite/MySQL/TDengine 都留在现场工控机或本地服务器上，前面架一个 Web 后端（.NET/Node），手机和总部通过浏览器访问后端接口。数据库只服务本地后端，不直接暴露到公网——这既是安全要求，也是性能考虑。选库时主要看本地业务规模，远程访问是后端架构的事。