工业网关的数据存进数据库，为什么查询越来越慢？从采集频率到存储策略的四个坑

做工业物联网项目，刚上线的时候一切正常。数据实时刷新，曲线平滑流畅，查询历史数据也是秒出结果。

但运行了半年、一年之后，问题开始出现了。平台上的数据查询越来越慢，打开一个历史趋势图要转半天圈，查一个月的数据甚至能把系统卡死。

这时候很多人第一反应是“服务器性能不够了”，于是加CPU、加内存。结果加完之后好了一阵子，过几个月又慢下来了。

其实，问题往往不在服务器硬件，而是在数据存储策略上。这篇文章把物联网数据入库和查询变慢的几个常见原因拆开说清楚。

一、第一个坑：采集频率一刀切，垃圾数据淹没了数据库

很多项目在配置采集频率时，为了图省事，把所有数据点的采集频率都设成一样的。比如全部设为1秒1次。

对于温度、湿度、液位这种变化极慢的物理量，1秒采集一次完全没有必要。室温可能几十分钟才变化0.1℃，你每秒存一条数据，数据库里90%以上的数据都是重复的无效值。

数据量有多大？假设有1000个数据点，1秒1次，一天就是8640万条记录。一年下来就是315亿条。没有任何一个普通的数据库能在这个量级下保持快速查询。

避坑建议：必须根据物理量的变化速度分级设置采集频率。温度、液位设10秒或1分钟一次；电流、电压设1-5秒一次；只有振动、瞬态波形才需要毫秒级采集。从源头减少垃圾数据的产生。

二、第二个坑：没有做历史数据降采样，全量存储

有些项目为了“保留所有数据”，把采集到的每一条原始记录都永久保存。

这就导致数据库无限膨胀。当你查询“过去一年的温度趋势”时，数据库需要从几亿条记录里把这部分数据全扫一遍，然后再画到屏幕上。这个过程会消耗极大的CPU和内存，查询当然慢。

避坑建议：必须实施分级存储和降采样策略。

• 最近7天的数据：保留原始精度（比如1分钟一条）。
• 7天到3个月的数据：按小时聚合（取平均值、最大值、最小值），数据量缩小60倍。
• 3个月以上的数据：按天聚合。
• 绝大多数场景下，看历史趋势只需要知道那个时间段的大致情况，不需要每一秒的细节。

三、第三个坑：数据库没有建索引，或者索引建错了

关系型数据库（比如MySQL）查询数据靠的是索引。如果你查询时用的是“时间范围”和“设备ID”，但数据库表里这两个字段没有建索引，或者只建了其中一个，数据库就会进行“全表扫描”。

全表扫描意味着数据库要把整张表（几千万条记录）从头到尾读一遍才能找到你需要的数据。这个过程极慢，而且非常消耗服务器资源。

避坑建议：确保数据库表在“设备ID”、“数据点ID”、“采集时间戳”这三个字段上建立了复合索引。并且，查询语句的编写顺序要和索引的顺序匹配。

四、第四个坑：数据库选型不对，用关系型数据库存海量时序数据

这是最致命的坑。

很多项目习惯用MySQL、SQL Server来存物联网数据。关系型数据库适合存订单、用户信息这种结构化数据，但它天生不擅长处理海量的、按时间顺序不断追加的时序数据。

专门处理时序数据的数据库（TSDB），比如InfluxDB、TDengine、TimescaleDB，它们底层是按时间分片存储的，查询时间范围的数据极快，压缩比也极高（能把几十亿条数据压缩到极小的空间）。

避坑建议：如果项目数据量不大（几百万条以内），用MySQL没问题。但如果数据点超过1000个，运行时间超过半年，强烈建议换成专门的时序数据库。

物联网数据查询越来越慢，根本原因是“垃圾数据太多”和“存储策略不对”。不要一遇到慢就加服务器。先把采集频率降下来，把降采样策略配上去，把数据库索引查一遍。

数据存得好，查询才能快。

你项目里的数据库跑了多久了？有没有遇到过查询特别慢的情况？最后是怎么解决的？评论区聊聊。