技术干货 · 工业数据与存储

工业时序数据库

为什么工业数据不能用 MySQL 存？

──────────────────────────────

三个特征 · 三大设计 · 压缩原理 · 降采样分层 · 实战案例

类型：技术干货　|　适用：工业物联网/数据平台/数字化项目从业者

关键词：时序数据库 · LSM-Tree · 列式存储 · Gorilla · 降采样 · 保留策略

⚡ 速读盒子 · 30秒看完核心

▸ 核心结论：工业数据“写多读少、海量高频、按时间范围查”，正好和关系数据库“读多写少”的设计前提相反。时序库靠三招翻盘：LSM-Tree 把随机写变顺序写、列式存储提高压缩与查询效率、时间分区让过期数据整块淘汰。再叠加 Delta-of-Delta 与 Gorilla XOR 压缩，实测压缩比普遍 10～20 倍

▸ 避坑要点：用 MySQL 存高频测点必然越写越慢、标签基数（Cardinality）失控会拖垮整个库、不做降采样和保留策略硬盘成本会失控、压缩比不是越高越好（要看查询是否需要原始精度）、别把“实时数据库”和“时序数据库”混为一谈

▸ 案例结果：写入吞吐提升 50 倍以上、存储占用降 12 倍、历史查询从“大面积超时”变秒级、硬盘成本省约七成

很多工厂的数字化项目，走到第二步就会撞上一堵墙：采集没问题、协议转换没问题、数据也顺利进了数据库——但系统跑了三个月，开始变慢。写入延迟从几毫秒涨到几百毫秒，查一个“最近一小时”的趋势要等十几秒，磁盘眼看着就满了。

问题不在采集，在存储。绝大多数团队的第一反应是“用 MySQL 存”——熟悉、稳定、生态好，团队也会用。但工业数据和业务数据是两种完全不同的东西：业务数据读多写少，工业数据写多读少；业务数据一天几千条，工业数据一天几亿条。用为“读多写少”设计的数据库去扛“写多读少”的负载，就像用家用轿车去拉集装箱——不是车不好，是用途错配。

一、工业数据的三个“怪脾气”：通用数据库为什么扛不住

图1：工业数据的三个特征，恰好命中关系数据库的三个结构性弱点

要理解为什么工业数据需要专门的数据库，先要理解工业数据长什么样。它有三个非常鲜明的特征，而这三个特征恰好和关系数据库的设计前提相反。

特征一，写多读少。一个典型的工业监控场景里，95% 的操作是写入——所有测点每秒都在产生新数据；读取只占 5% 左右，而且多半是“看一眼当前值”或“拉一段历史趋势”。而关系数据库（比如 MySQL）是为“读多写少”的业务系统设计的，它的索引结构（B+ 树）为快速查询做了大量优化，代价是每次写入都要同步维护索引——数据量一大，随机写就把磁盘 IO 打满了。

特征二，海量高频。10 万个测点、1 秒采集一次，一天就是 86 亿条记录；如果是振动、电流这类需要高频采样的信号（比如 1kHz），数字还要再翻几个数量级。这种量级下，关系库的索引会持续膨胀——索引越大，每次写入要更新的层级越多，写入速度就越写越慢。这是典型的“越用越慢”，而且靠加硬盘解决不了。

特征三，按时间范围查。工业数据的查询模式高度固定：永远是“最近一小时”“昨天全天”“上个月的趋势”这类时间窗口。关系库的索引是按值（比如设备ID）组织的，对“时间范围”这个维度没有针对性优化，大范围查询往往退化成扫描大量数据行。

把这三条放在一起看，结论就很清楚了：工业数据“只追加、不更新、按时间查、量极大”，而关系库“为更新和随机查询优化”。这不是调参能解决的错配，是结构性的。所以正确的做法不是“把 MySQL 优化得更好”，而是换一个为这种负载从设计之初就优化过的数据库。

Q: 把 MySQL 分表、加索引、上集群，能解决问题吗？

A: 能缓解，但不能根治，而且成本会越来越高。分表确实能把单表变小、缓解索引膨胀，加索引能改善部分查询——但这些都是在“读多写少”的框架里做优化，没有改变“每次写入都要维护索引”这个根本矛盾。分表分到几百张之后，运维复杂度、跨表查询、扩容难度都会急剧上升，最终变成一个没人敢动的系统。真正划得来的做法是分工：高频测点的原始数据交给时序数据库，业务数据（工单、订单、设备台账）继续留在关系库，两者通过设备ID和时间戳关联。用对工具，比把一个工具用到极限更省成本，也更可持续。

二、快 100 倍的三招：写入、存储、淘汰各管一段

图2：时序数据库的三大核心设计，分别解决写入、存储与淘汰三类问题

时序数据库能把性能拉开上百倍，不是靠某一项黑科技，而是三招组合——每一招针对上面三个特征中的一个。

第一招，用 LSM-Tree 把随机写变成顺序写。传统数据库的写入是“原地更新”，随机 IO 很慢。LSM-Tree 的思路完全不同：新数据先写进内存（MemTable）并追加一条顺序日志（WAL，保证掉电不丢），等内存攒够一批，再一次性批量刷到磁盘。整个过程磁盘只做顺序写——顺序写的吞吐通常是随机写的几十倍。这就是时序库写入吞吐能拉开数量级的根本原因。

第二招，按列存储。关系库按行存：一行的所有字段挨在一起。时序库按列存：同一列（比如所有测点的温度值）连续放在一起。这么做有两个好处：一是同列数据类型完全一致、数值范围接近，压缩效率极高；二是查询“只取温度这一列”时，不需要读取整行数据，IO 量大幅下降。

第三招，按时间分区。数据按时间段切成一个个独立的块（比如按天或按小时）。新数据只写入最新的那个块，老块不再变动；数据过期时，整块删除即可——不用逐行扫描删除，几乎零成本。这一招让时序库在“保留 7 天原始数据”这类需求上非常轻松，而关系库删几亿行老数据往往是一场运维事故。

这三招合起来，构成了时序库的基本骨架。需要说明的是，具体实现各家不同——有的用 LSM-Tree 加列式，有的用时间分区加列式，有的在关系库之上做扩展。但思路是一致的：让写入变成顺序追加，让存储变成按列压缩，让淘汰变成整块丢弃。理解了这三条，再看任何一款时序数据库的架构文档，都能快速看懂它在解决什么。

Q: 时序数据库和“实时数据库”是同一个东西吗？

A: 不是，两者容易混淆但定位不同。实时数据库（RTDB）的核心目标是“内存里的当前值”——毫秒级刷新、面向监控画面和报警，典型代表是组态软件里内置的那套实时库，它关心的是“现在是多少”。时序数据库（TSDB）的核心目标是“历史数据的长期存储与查询”——高吞吐写入、高压缩比、按时间范围分析，它关心的是“过去是怎么变的”。真实的工业数据平台里，两者通常是配合关系：实时数据库负责当前值刷新与报警，时序数据库负责历史归档与分析。如果项目里有人拿“实时数据库”当“时序数据库”选型，往往会在历史数据量上来之后才发现问题。

三、压缩：工业数据的“省钱密码”

图3：时间戳用 Delta-of-Delta、浮点用 Gorilla XOR，两者叠加实现十倍以上压缩

时序数据库能“存得起”海量数据，压缩是绕不过去的一环。工业数据的压缩之所以能做得特别好，是因为它有两个天然的规律性，而这两条规律正好被两个经典算法利用。

第一条规律：时间戳高度规律。工业采集通常是等周期的——每秒一个点、每分钟一个点。Gorilla 论文提出的 Delta-of-Delta（二阶差分）编码正是利用了这一点：先算相邻时间戳的差值（Delta），再算差值的变化（Delta-of-Delta）。如果采样周期稳定，一阶差值恒定，二阶差值就是 0——而 0 几乎不占存储空间。原本需要 8 字节的时间戳，压缩后常常只需要几个 bit。

第二条规律：数值变化平缓。温度、压力、转速这类物理量，相邻采样点之间变化很小。Gorilla 用 XOR 编码处理：把当前值和上一个值做异或运算，如果两个数很接近，异或结果的高位会全是 0，只有少数低位有效——那就只存这几个有效位。数值变化越平缓，压缩效果越好，而工业物理量恰好普遍变化平缓。

这三类算法叠加，工业时序数据的实测压缩比普遍在 10 到 20 倍——有公开测试显示，一段物联网温度数据压缩后体积只有原来的 1/12 左右。这个数字的工程意义很直接：原本要 12 块硬盘才能存一年的数据，现在 1 块就够。这也是为什么时序数据库能把长期存储成本压下来。

⚠ 压缩不是越高越好：先想清楚查询要不要原始精度

压缩比是个很诱人的数字，但选型时不能只比这个。压缩是“拿解压换空间”，压缩比越高，解压开销往往越大，查询时 CPU 消耗也越高。更关键的是精度问题：如果用了有损压缩（比如把浮点量化成定点），历史数据就不再是原始精度，事后做故障复盘、算法训练时可能不够用。正确的判断顺序是：先明确“历史数据要用来做什么”——如果只是看趋势，有损压缩没问题；如果要用于故障追溯或模型训练，就必须保留原始精度。先定用途，再定压缩策略，最后才比压缩比。反过来先看压缩比选型，很容易在后期发现“数据存下来了，但用不了”。

四、降采样与保留策略：别让硬盘成本失控

图4：数据的生命周期——精度随年龄递减，成本随年龄递减

就算压缩做到 20 倍，一个 10 万测点的系统如果全精度存五年，硬盘成本依然会失控。所以时序数据库还有一个必须掌握的机制：数据分层。核心原则只有一句——精度随“年龄”递减，成本随“年龄”递减。

具体做法是把数据按时间分成三层。第一层是原始数据，秒级全精度，只保留最近 7 天左右，放在最快的存储上——它的用途是故障追溯和实时报警，需要最细的粒度。第二层是降采样数据，把秒级数据聚合成分钟级（比如取平均值、最大值、最小值），保留一年——它的用途是趋势分析和同期对比，分钟粒度足够。第三层是归档数据，再聚合成小时级，保留五年——它的用途是长期报表和合规存档。

这三层之间的转换不需要人工干预，靠两个机制自动完成。连续查询（Continuous Query，CQ）负责“该聚合就聚合”：按预定周期把秒级数据自动聚合成分钟级、小时级。保留策略（Retention Policy，RP）负责“该删就删”：到期的数据自动清理，不占用宝贵的高性能存储。两个机制配合，数据就形成了一个自动流动的生命周期。

这套机制的价值不只是省硬盘。它还有一个容易被忽略的好处：查询变快了。因为绝大部分历史查询（看趋势、出报表）其实不需要秒级精度，直接查降采样后的分钟级数据，数据量小一个数量级，响应自然快。真正需要秒级细节的场景（比如复盘某次故障的瞬间波形），才去查最近 7 天的原始数据。用分层的方式把“精度”和“用途”对齐，是工业数据平台能长期跑下去的关键。

Q: 保留 7 天原始数据，会不会导致故障复盘时数据不够用？

A: 要分场景看，不能一刀切。对于“事后复盘某次故障”，7 天窗口通常够用——因为故障处置一般发生在当天或次日，原始数据还在。真正需要警惕的是两类场景：一是“延迟很久才发现的问题”（比如三个月后才发现某批产品质量异常，要回溯当时的工艺参数），二是“合规要求长期留存原始数据”（比如某些行业要求关键参数留存数年且不能降精度）。这两类场景必须在方案阶段就识别出来，对相关测点单独设置更长的原始保留期，或者单独做一份高精度归档。正确的做法是“分层保留 + 关键测点例外”：绝大多数测点走标准三层策略，少数关键测点单独配置。把所有测点都按同一套策略处理，才会真的出事。

五、案例故事：10 万测点的存储改造

客户背景

某制造企业，三条主力产线做设备状态与能源计量采集，测点规模约 10 万个，覆盖振动、温度、电流、能耗等信号，采集周期 1 秒。按这个规模算，每天新增约 86 亿条记录——项目上线前，团队用的是团队最熟悉的 MySQL。

一期受挫：硬扛 MySQL

第一期的做法是“优化到极限”：加索引、按月分表、加磁盘、上主从。结果是短期缓解、长期恶化——写入延迟从几毫秒一路涨到几百毫秒，磁盘 IO 长期打满，单表很快突破 10 亿行，历史趋势查询开始大面积超时。更麻烦的是，分表分到几十张之后，跨表查询和扩容都变得极其复杂，运维团队开始不敢动这套系统。核心问题始终没变：这是负载类型错配，不是参数没调好。

二期转向：换时序数据库，按测点建模

复盘后，方案做了根本调整：高频测点的原始数据从 MySQL 迁到时序数据库，按“测点即标签”的方式建模——设备ID、测点类型、产线编号作为标签（tag），时间戳作为主键，数值作为字段。写入走 LSM-Tree 顺序落盘，数据按天自动切块。这一改，写入吞吐立刻上了一个数量级，压缩比实测约 12 倍，存储压力大幅缓解。业务数据（工单、台账）继续留在关系库，两者按设备ID和时间戳关联。

三期闭环：降采样 + 冷热分层

第三期把数据分层机制补齐：秒级原始数据只保留 7 天，分钟级聚合数据保留 1 年，小时级归档数据保留 5 年，全部通过连续查询自动生成、保留策略自动清理。同时把历史查询按用途分流——看趋势查降采样数据，复盘故障查原始数据。至此，系统在 10 万测点的规模下稳定运行，硬盘成本相比“全精度全留存”的方案省了约七成。

三个教训值得所有工业数据平台借鉴：

教训一：先认清负载类型，再选数据库

一期不是 MySQL 用错了，是“用错场景”——把为读多写少设计的库，拿去扛写多读少的负载。选型第一步不是比参数，而是先把负载特征写清楚：读写比例、数据量级、查询模式、更新频率。特征清楚了，工具自然就选对了。

教训二：标签基数要提前控制

时序数据库有一个隐形的性能杀手：标签基数（Cardinality），也就是不同标签组合的数量。如果拿设备序列号、订单号这类“几乎不重复”的值当标签，标签基数会爆炸式增长，索引和元数据膨胀，查询性能断崖式下跌。正确做法是：标签只放“取值有限、会重复”的维度（产线、设备类型、区域），高基数的信息放到字段里。这一条在建模阶段就要定死，后期很难改。

教训三：分层策略要和用途对齐

保留多久、降采样到什么粒度，不该拍脑袋定，而要看数据“将来用来做什么”。看趋势的用分钟级就够，做故障复盘的必须留秒级，合规存档的可能要留数年。先梳理用途，再定策略，最后才配参数——顺序反了，要么数据不够用，要么成本失控。

"“我们花了大半年优化 MySQL，最后才想明白一件事：不是它慢，是我们用错了地方。换库之后，之前那些‘优化难题’大部分自己就消失了。"

—— 项目技术负责人

Q: 工业项目该选哪款时序数据库？有没有通用答案？

A: 没有通用答案，但有一套通用的判断方法。先看四件事：一是写入吞吐能不能扛住你的峰值（按测点数×采集频率估算，留 2～3 倍余量）；二是压缩比与查询性能是否平衡（别只看压缩比）；三是部署形态是否符合你的环境（纯本地、边缘轻量、还是云原生）；四是生态与运维成本（有没有现成的可视化、告警、迁移工具，团队能不能维护）。常见的候选包括面向物联网场景的 TDengine、生态成熟的 InfluxDB、以及可扩展时序能力的 TimescaleDB、ClickHouse 等。选型时建议先用真实数据做一轮压测——用自己 10% 的真实测点跑一周，比看任何评测报告都可靠。

六、总结：上工业数据平台之前三问

回顾全文，选存储方案之前，问自己三个问题：

⚡ 一问负载特征是什么：读写比例、数据量级、查询模式、更新频率——这四项先写清楚。工业数据“写多读少、海量高频、按时间范围查”，用关系库硬扛必然越用越慢，这是结构性问题，不是调参能解决的。

🔍 二问标签基数控没控住：标签只放取值有限、会重复的维度；设备序列号、订单号这类高基数值放到字段里。标签基数失控是时序库最隐蔽的性能杀手，必须在建模阶段就定死。

🔁 三问分层策略和用途对不对齐：原始数据留多久、降采样到什么粒度，要看数据将来用来做什么。分层保留 + 关键测点例外，既能压住成本，又能保证该细的地方细得起来。

从产业看，工业时序数据正在从“存不存”变成“怎么存得起、用得好”。市场研究机构预测，全球时序数据库市场规模将从 2025 年的约 28 亿美元增长到 2034 年的约 267 亿美元，年均复合增速接近 28.5%；中国实时数据库市场 2026 年预计达 159.1 亿元、同比增长 23.7%，其中本地实时数据库市场约 63.8 亿元、同比增长 22.5%。增速背后是同一个推力：设备越来越多、采样越来越密、数据保留越来越长。当“数据存不动”成为数字化项目的普遍瓶颈时，选对存储层，就从技术细节变成了项目成败的关键。

你的数据平台，还在用 MySQL 硬扛高频测点吗？

工业数据存储 · 采集上云 · 数据平台方案设计

技术干货 · 工业物联网系列

关注我们，持续拆解工业物联网技术的原理与实战