工业历史数据用什么存？
MySQL vs TDengine / InfluxDB

选型争论之前，先把自己的数据量算出来，这是最客观的依据（假设每个点位每次采样落一行）：

举个最常见的产线例子：500 个点、每 2 秒采一条 = 250 行/秒，一天 2160 万行，一年约 78.8 亿行。按行存约 50 字节/行（含主键、设备、点位、时间、值和索引）估算，一年约 394 GB；时序库列存压缩后通常只有 约 1/10（40 GB 上下）。这还没算查询变慢和备份成本。

• 预计单表 超过 1000 万行，开始评估时序库；
• 单表 上亿、查一条曲线要几秒、磁盘每月涨几十 GB，立刻上；
• 即使量不算大，但要存多年趋势、做降采样聚合、多机联网看板，也建议直接上时序库。

注：磁盘按每行约 50 字节、时序库列存压缩约 1/10 的工程量级估算，实际与数据类型、压缩算法、是否含索引强相关，正式选型请以实测为准。

不是 MySQL 不好，而是负载不对口。工业点位数据有鲜明特点：只追加、几乎不修改、带时间戳、按时间范围查、数据结构高度同质、要长期保留。这恰好是通用 OLTP 关系库最不擅长的活：

• 写入：B+ 树索引在持续高频插入下要不断分裂、刷盘，写得越久越慢，还得靠批量插、关索引、分表来扛。
• 查询：看板几乎都是"查某设备最近 1 小时趋势""昨天某班曲线"，关系库靠索引扫，单表上亿后一次查询几秒到几十秒。
• 压缩：行存对大量重复结构的数值压缩率极低，磁盘占用是时序库的约 10 倍。
• 生命周期：没有内置时间窗口聚合、降采样、自动过期，全要自己写定时任务和 DELETE，删海量历史数据本身就是灾难。

时序数据库就是针对"高写入、按时间查、自动压缩、自动过期"这四件事重新设计的——按时间顺序追加写、列存高压缩、时间分区让范围查询毫秒级、原生降采样和保留策略。

一个成熟的工控系统，业务数据（用户、权限、工单、配方、报警主数据、台账）放 MySQL，点位历史放 TDengine 或 InfluxDB，可视化用 Grafana。强行用 MySQL 存时序数据，或者反过来用时序库存业务数据，都是拿工具的短板去硬扛。

很多项目是"先用 MySQL 跑起来，量大了再优化"，这很正常。我的建议是旁路并行、逐步切换，而不是停机重构：

1. 新数据先旁路：新增的点位数据通过 Telegraf / Neuron / ThingsGateway 等采集器，一路写 MySQL（保留）、一路写时序库（新增），业务系统不动。
2. 业务数据留 MySQL：用户、工单、配方、报警主数据、设备台账继续用关系库，不要迁。
3. 历史数据分批导：按时间把旧数据导出成 CSV，批量导入 TDengine，导完一批核对一批，避开停机窗口。
4. 应用层统一接口：趋势/曲线查询读时序库，业务查询读 MySQL，上层通过统一数据访问接口屏蔽底层，以后换库也不影响应用——这也是我在通讯库里一直强调的"应用与存储解耦"。

迁移前，还可以先在采集侧做死区上报、分级采样、降采样，把不必要的写入量先降下来（见 FAQ 最后一条），很多项目这样优化后规模本身就小了一大截。

我在冲床监控、能源管理、OEE 这些项目里，点位历史基本都用 TDengine，业务数据放 MySQL/PostgreSQL，看板用 Grafana——这套分工让我在 30 台冲床、几千点的规模下，采集存储基本不用操心磁盘和查询。

但我也经常帮小项目主动克制：一个单机检测设备、几十点、数据就给操作工看几天，我会直接用 SQLite，绝不为了"技术先进"硬塞时序库。选型的核心不是追新，而是先算清自己的数据量和使用场景。

真正要避免两种极端：一是该上不上，让 MySQL 硬扛几十亿行，最后查询超时、磁盘爆满；二是不该上乱上，几十点的小项目也搞一套时序库集群，增加运维负担。按上面那张规模表对号入座，基本不会错。