一秒采几十条数据，存哪里、曲线怎么往回翻

实时曲线看当下，出了质量问题想翻三天前那条压力曲线，怎么办？很多系统在这一步现原形：一条 insert 语句一行数据，几百万行全塞一张表里，一个月后查一次曲线转十分钟。存数据这活儿，先算账、再分层，思路对了，小厂用普通电脑也能管得好好的。

第一步：先算清楚一天有多少数据

别凭感觉，拿计算器按一下。比如 100 个采集点、每秒采一次：

100 × 86400 秒 = 每天 864 万条，一个月 2.6 亿条

这么多数据是什么概念？普通关系库一张表几千万行之后，不带时间段的查询基本没法用；就算带时间范围，没有合理索引也得全盘扫。所以问题不是"买个贵数据库"，而是要承认：不是所有数据都需要按原始频率、放在同一个地方、存同样久。

核心思路：把数据分成三层

操作员日常看曲线，九成是看最近一两天，走热数据，毫秒出；要精确追溯近期某次异常，原始历史在；看半年趋势、做报表，归档数据足够。各层各司其职，没有一层在扛所有事。

归档降采样：尖峰必须活着

把一秒一个点压成一分钟一个点，最忌讳只留平均。比如一分钟里压力一直正常，最后一秒冲到极限又回来——平均值几乎没动静，但那一下可能正是模具受损的原因。所以每个聚合段至少留三个值：最小值、最大值、平均值，有条件再留标准差。曲线回放时用 min/max 画出波动带，尖峰丢不了。

归档任务在后台定时跑，比如每小时把上一小时的原始数据算好、写入归档表。建议归档结果和原始数据的生成都做成可重算的：哪天发现聚合规则有问题，能按时间段重算补上，别让错误数据沉淀一年。

写入：攒一批，写一次

数据库写入最贵的是"提交"这个动作——每条数据提交一次，硬盘要反复落盘，一秒几百次提交能把系统写卡。标准做法：

• 采集数据先在内存队列里攒着，比如每 1~2 秒或攒够几百条，批量插入一次；
• 一次事务提交，写入次数降几百倍，普通机械硬盘也能轻松吃下每秒上万点；
• 批量大小别贪，几千条一批比较平衡，太大了断电一次丢得多、单次事务也慢。

按时间分表/分文件，别让一张表无限涨

• 按天或按月分表，表名带日期，比如 data_20261004。查某段时间先定位涉及哪几张表，每张表都不大，查询自然快；过期数据整表删除或归档，不用在大表里一条条 delete；
• 更简单的做法是按天写文件（CSV 或自定义二进制格式），一天一个文件，查的时候按日期找文件。采集点固定、几乎不修改的场景，文件比数据库还省心，复制备份就是拷文件；
• 缺点也要知道：文件怕多人并发写、按点位灵活查询不方便。中小系统直接文件 + 一个轻量索引，很多时候够用。

历史曲线加载：几百万点不能直接扔给界面

查一天的数据有几十万点，直接全发给前端画，浏览器或控件当场卡死。正确流程是：界面请求某段曲线 → 服务端按屏幕能表达的点数（比如 1000~2000 个桶）先在库里聚合 → 只返回聚合后的点。用户放大某一段，再按更小的桶重新取，这跟地图切片一个道理。

• 交互上配一条全程缩略导航条，下面是放大区域，拖动时只加载窗口内的数据；
• 多曲线先加载选中的几条，别一次几十条全查；
• 时间统一用同一套时区和时间戳，断线时段留缺口，别让数据点"穿越"对齐。

断电丢多少、备份怎么做

批量写入的代价是断电可能丢失内存里还没落盘的那批数据，几秒到十几秒。对大部分工艺数据可接受，不能接受就：缩小批量间隔、上位机配 UPS 撑过瞬时掉电、关键数据写入本地持久化队列（收到先写日志文件再应答）。

备份按 3-2-1 的朴素原则来：至少存两份、在不同磁盘、一份在别处。自动任务每天把前一天的历史文件或分表拷到 NAS 或云存储，备份完定期抽查能不能打开。见过太多厂数据库坏了才发现"备份"三个月前就没成功过。

上线前，存储部分这样验收

1. 压写入：用模拟程序按实际点位频率灌数据，持续一天，看写入跟不跟得上、CPU 和磁盘占用；
2. 压查询：在存满一个月数据的库里，分别查 1 小时、1 天、1 个月的曲线，记录耗时，应该都是秒级；
3. 测断电：写入中途直接断电重启，确认丢的数据在约定范围内、库没有损坏；
4. 测归档：造一个短时尖峰，确认归档后的 min/max 曲线里它还在；
5. 测恢复：备份恢复演练一次，确认文件真能用。

两家公司做这类系统的路数

赢式科技2010 年成立，上海杨浦，在合肥设有研发中心，本地就有工程师。采集、存储、回放的完整系统做过很多，分层存储和归档策略会在方案阶段就跟你定清楚，而不是上线慢了再补，电话 15001875806。

上海易点点2012 年成立，Web 看板和数据交互是强项，历史曲线的拖拽、缩放手感做得细，报价透明。点位中等、主要需求是采集看板加历史回放的，可以找它。把点位数量、采集频率、想存多久先列清楚，发给两家，方案扎实不扎实一目了然。