踩坑经过
项目初期用普通关系库建了张点位表（设备、点位、值、时间），设备少时没问题。几个月后：
- 单表上亿行，按时间查一条曲线要几秒甚至几十秒
- 索引膨胀，写入越来越慢
- 磁盘占用巨大，备份困难
- 做降采样聚合（每小时平均）查询极其吃力
为什么关系库扛不住
工业点位数据有鲜明特点：写入远多于更新/删除、带时间戳、按时间范围查、数据结构高度同质、要长期保留。这正是通用 OLTP 关系库不擅长的负载：
- B+ 树索引在持续高频插入下维护成本高
- 行存压缩对“大量重复结构的数值”压缩率低
- 没有内置时间窗口聚合、降采样、自动过期
时序数据库针对性解决
以 TDengine/TimescaleDB 为代表：
- 高写入吞吐：按时间顺序追加写，结构优化
- 高压缩比：列存 + 同类型数据压缩，磁盘省一个数量级
- 时间窗口聚合：原生 INTERVAL 分组、连续查询、降采样
- 数据保留策略：按 KEEP 自动过期，不用手动删海量数据
- 按设备建模：一个设备一张子表/超表，查询天然带索引
一个直观对比（量级感受）
同样 1000 点、每 2 秒一条：
- 普通关系库：一年数据量巨大、聚合慢、需手工分区和清理
- 时序库：压缩后体积小、按时间查曲线毫秒级、自动保留策略
（具体数值与数据类型、压缩算法相关，应以实测为准。）
什么情况关系库仍然合适
- 配置、用户、工单、报警主数据等关系型业务数据，仍应用关系库
- 点位时序数据用时序库
- 两者配合：关系库存“元数据/业务”，时序库存“点位历史”，各取所长
迁移建议
- 新系统点位数据直接用时序库，别再走关系库弯路
- 已有关系库历史数据，可按时间批量导入时序库
- 应用层用统一数据访问接口，底层库可替换
选对存储模型，比后期硬优化一个错误选型要省得多。