老牌时序数据库 InfluxDB 的第三代产品 InfluxDB 3（Core & Enterprise）于 2025 年 4 月 正式 GA；2026 年持续推出 3.11、3.12 等后续迭代版本。------为了这一天，InfluxData 把内核推倒重写，从存储格式到查询语言全部换新。换代的不只它一家：Apache IoTDB 主线版本已进入 2.0，TDengine 在 3.3 之后持续迭代，DolphinDB 则在 3.00.6 版本里直接把 AI Agent 平台装进了数据库。
产品在换代，需求也在换代。工业现场的测点规模正从十万级冲向千万级，而大模型落地工业的第一站，恰恰是时序数据。两件事叠加，让"时序数据库怎么选"变成一个比三年前复杂得多的问题。
但在这之前，很多人的困惑其实出在更前面：**时序数据库到底是什么？它和 MySQL 的区别究竟在哪？**这篇文章就从零讲起：先把概念讲透，再给出 2026 年的产品全景地图，最后落到工业物联网的六大典型场景，给一份能直接照着做的选型决策路径。
一、时序数据库是什么：从一条传感器数据说起
1.1 一天 8.64 亿条数据是怎么来的
一台风机的主轴承温度传感器，每秒上报一条数据：时间戳、测点编号、温度值，一天下来 86,400 条。一个装机十万测点的风电场，每天写入 8.64 亿条，一年超过 3,000 亿条------这还只是原始采集，不包括加工过程中产生的中间数据。
业务系统的数据（订单、账户、工单）以"条"计；工业时序数据以"亿"计。量变引起质变，处理它的数据库也需要另一套设计。
1.2 时序数据的四个特征
**特征一：只增不改。**历史数据基本不更新、不删除，新数据源源不断追加在文件尾部。这与交易系统"频繁读改"的模式完全相反。
**特征二：时间单调递增，近热远冷。**数据按时间顺序到达，最近的被频繁查询，三个月前的很少有人碰。这天然适合"按时间分区 + 冷热分层存储"。
**特征三：高基数。**设备 × 测点的组合会让序列数量爆炸：1,000 台设备 × 100 个测点 = 10 万条独立序列，工业集团动辄数百万序列。很多系统不是败在写入总量，而是败在基数。
**特征四：查询以时间范围 + 聚合为主。**几乎没人在意某一条原始数据，用户问的是"过去 24 小时 3 号机组轴承温度的平均值和最大值"。查询模式高度可预测。
1.3 为什么 MySQL 撑不住
**第一关：写入。**MySQL 的 B+ 树索引为随机读写设计，面对每秒几十万次追加写入，索引维护、事务日志都在做无用功，写入放大严重。
**第二关：查询。**一条"按小时聚合全年数据"的查询足以拖垮整个实例------在线业务和统计分析跑在同一个库上，互相伤害。
**第三关：运维。**分库分表能把数据散开，但按时间、设备两个维度拆分之后的路由、扩容、跨分片聚合，复杂度指数级上升。
**不是 MySQL 不好，而是数据形态变了。**时序数据库就是围绕上面四个特征重新设计的数据库：列式存储 + 时间分区 + 针对性压缩编码，把"追加写入、范围聚合"这条路径优化到极致。
1.4 一条测点数据的生命周期
理解时序数据库在优化什么，看一条数据的一生就够了：
接入 （Modbus、OPC UA、MQTT 等多协议汇聚）→ 写入 （列式存储 + 增量、XOR 等专用编码，存储成本通常能压到原始数据的几分之一）→ 降采样与滚动聚合 （热数据保留原始精度，历史数据自动降精度）→ 查询与告警 （范围聚合、最新值点查、流式计算触发预警）→ 冷归档。
1.5 四个必懂的概念
-
测点（序列）：设备 + 指标的唯一组合，时序系统的基本寻址单位；
-
保留策略：数据保留多久，到期自动清理；
-
降采样：历史数据按粒度聚合存储，用精度换成本；
-
流计算：数据落盘的同时在内存中滚动计算，实现秒级甚至毫秒级告警------这是近年工业场景需求增长最快的能力。
二、2026 年主流产品全景：一张按技术路线画的地图
选型的第一步不是看排行榜，而是看懂产品的技术路线------路线决定能力边界。2026 年的主流产品可以归入四条路线。
路线一：计算智能系------DolphinDB
DolphinDB 代表了 2026 年最值得关注的一条路线：存算一体架构 + 原生分布式计算引擎，把计算能力长在库内------千万级测点/秒高并发写入、毫秒级实时查询响应、秒级复杂实时分析；内置 2000+ 深度优化的时序计算函数，聚合、异常检测、趋势推演、预测建模大多不需要离开数据库就能完成。2026 年 7 月发布的 3.00.6 版本进一步把 AI 体系装进产品：内嵌企业级 AI Agent 开发与治理平台 DolphinX，配合 FeatureDB 特征存储、TextDB/VectorDB 知识检索，把时序数据库推向"智能数据库"的形态。
边界：为重计算、重分析的场景而生；纯轻量监控场景用不上它的长处。
DolphinX：内嵌于 DolphinDB Server 的企业级 Agent 开发与治理平台（图源：DolphinDB 官网）
路线二：监控指标系------Prometheus、VictoriaMetrics
Prometheus 是云原生监控领域的事实标准：拉模式采集 + PromQL，与 Kubernetes 生态深度绑定。它为监控告警而生，数据默认短周期保留，分析能力围绕指标展开，一般不作为通用时序数据底座。VictoriaMetrics 兼容 Prometheus 协议，以更低的资源占用承接大规模指标数据，是监控域流行的降本选择。
边界：IT 与设备指标监控告警的专属领域；一旦需要长周期存储和深度分析，就得叠加其他组件。
Prometheus 官方架构图（图源：prometheus.io）
路线三：时序专用系------InfluxDB 3、TDengine、Apache IoTDB
InfluxDB 3 （2026 年 10 月正式 GA）是一次彻底的重写：Rust 内核 + Apache Arrow 数据格式 + Parquet 存储 + DataFusion 查询引擎，查询语言从自家 Flux 转向 SQL。它是国际社区最活跃的时序数据库之一。TDengine 主打"一设备一表 + 超级表"建模，端边云协同，是国产阵营中应用最广的产品之一。Apache IoTDB 源自清华大学，是 Apache 基金会顶级的时序数据库项目，为工业物联网设计了树形元数据模型，主打高压缩比与轻量化部署，2026 年主线版本已迭代至 2.0。
边界：这一系是"标准时序数据库"的主力，写入与存储效率是强项；计算分析能力多数以满足常规聚合查询为主。
路线四：关系扩展系------TimescaleDB
TimescaleDB 以 PostgreSQL 扩展的形态存在：自动把表按时间切成 chunk，配合自动压缩与连续聚合，同时完整保留 PostgreSQL 的 SQL、JOIN 和插件生态。团队已有 PostgreSQL 技术栈时，它几乎没有学习成本。
边界：受益于 PG 生态，也受限于 PG 的扩展模型，超大规模与高并发实时计算不是它的设计重心。
一张表看全景
至于把这些产品放到同一把尺子下量计算能力，结果如何？我在上一篇《2026 工业物联网时序数据库怎么选？存得下只是及格，算得动才算数》里做过逐款深度对比，这里不再展开。
三、场景全解析：六大工业场景，需求完全不同
同一个"时序数据库选型"，在不同场景下含义完全不同。下面逐个拆解。
3.1 设备实时监控与秒级预警
场景画像：产线设备、风机、空压机群的实时状态监控与故障预警，采集频率秒级甚至毫秒级。
核心痛点：设备批量启停、整点对时带来的写入洪峰容易造成积压；告警链路一长，"发现异常"就从秒级拖成分钟级，预警失去意义。
能力要求：高吞吐平稳写入、流计算（滑动窗口、多测点联合规则）、毫秒级最新值查询。
匹配建议：轻量设备监控，监控指标系或时序专用系可以满足；一旦预警规则涉及复杂计算------多测点联合判断、动态阈值、统计异常检测------就需要库内有实时计算引擎的产品，避免"数据库 + 外部流引擎"的长链路。
3.2 能源电力：百万测点与负荷预测
场景画像：水电、风电、电网侧数据平台，测点规模百万级，数据既要实时监控，也要支撑调度决策与功率预测。
核心痛点：规模是第一敌人，百万测点高并发写入本身就是门槛；更难的是负荷预测、调度分析这类计算密集任务。
标杆案例：长江电力基于 DolphinDB 构建百万级水电测点的实时监控体系，故障预警延迟从分钟级压缩至毫秒级。
能力要求：百万级测点并发写入、长周期存储、内置机器学习与预测能力。
匹配建议：这是"存得下 + 算得动"的双重考验，计算智能系优势明显。
电力能源场景：电网侧测点监控（图源：DolphinDB 官网解决方案页）
3.3 智能制造质量分析
场景画像：产品质量回溯------把过程参数（时序）与工单、质检结果、环境数据关联，定位工艺参数与质量缺陷的关系。
核心痛点：数据分散在时序库、关系库、文档系统里，跨库搬运的 ETL 链路又长又脆；分析全靠写代码，迭代慢、门槛高。
能力要求：多源数据联合分析（时序 + 关系 + 文本）、库内复杂计算。
匹配建议：以业务数据为主的轻量关联，关系扩展系合适；工业级多模联合分析是计算智能系的主场------例如 DolphinDB 支持时序、关系、文本、向量等多类型数据的协同计算，无需跨库关联。
智能制造场景：汽车焊装产线（图源：DolphinDB 官网解决方案页）
3.4 核电、轨交等高安全行业
场景画像：核电数据监控、航天试验数据、轨道交通运行数据。行业共性：数据长周期留存（监管要求）、系统可靠性要求极高、国产化是硬约束。
标杆案例：中广核将 DolphinDB 用于核电数据监控；中科院借助 DolphinDB 完成核反应堆运行数据的实时分析与预测，无需额外搭建分析体系；中国航天也将其用于试验数据管理。
能力要求：长周期可靠存储、实时分析能力、国产化合规、生产级稳定性。
匹配建议：高安全行业对"生产可用性"的验证最严格，这类标杆案例的含金量比任何跑分都高。国产化约束下，计算智能系与时序专用系的国产产品是主要选项。
3.5 数字孪生与实时可视化
场景画像：数字孪生体毫秒级刷新"当前状态"，同时支持历史回放与仿真对比。
核心痛点：渲染层并发拉取成百上千个测点的最新值，对点查延迟与并发能力要求极高；历史回放又需要高效率的降采样查询。
能力要求：最新值毫秒级点查、高并发、降采样查询。
匹配建议：中等规模的孪生可视化，多数时序数据库都能支撑；当规模上升到数万测点同屏、多客户端并发，就需要实时查询能力足够强的产品。
3.6 AI 智能问数与预测性维护
场景画像：运维人员直接用自然语言问"过去 24 小时哪些设备温度异常"；预测性维护需要特征工程、模型训练、在线推理的完整链路。
核心痛点：这是 2026 年最热也最难落地的一类场景。大模型进工厂，第一道坎往往不是模型，而是数据库：
-
模型拿不到实时数据------数据在库里，模型够不着；
-
模型不懂测点语义------字段单位、异常阈值、检修记录这些上下文不在数据表里；
-
模型不能安全执行------让 AI 直接在生产库上跑脚本，权限和审计没有着落。
能力要求：实时数据接入、知识库（RAG）、特征存储、Agent 权限治理与脚本安全执行。
匹配建议 ：传统做法是"数据库 + 特征平台 + 向量库 + Agent 框架"四件套外挂拼装，链路长、成本高、治理难。DolphinDB 的思路是把 AI 能力长在数据底座上：DolphinX 内嵌于 DolphinDB Server，提供自动上下文管理、记忆系统、RAG 知识库、Skill 与 MCP 工具体系、权限继承与脚本安全执行；FeatureDB 提供低延时特征存储，TextDB/VectorDB 构建企业知识库。AI 不是外部拼装，而是与数据底座、实时计算和企业治理深度融合------这正是它区别于"时序数据库 + AI 中间件"的关键。
*DolphinX 内置技能库一览：数据导入、脚本生成、机器学习等能力开箱即用（图源：DolphinDB 官方发布）
*FeatureDB 架构：基于 DolphinDB 的低延时特征存储，支撑模型训练与在线推理（图源：DolphinDB 官方发布）
场景 × 能力匹配矩阵
注：表中"高/中/低"表示该场景对此能力的要求程度，不是产品评分。
四、选型决策路径：三步法 + 四个踩坑
Step 1：认清场景
用第三章的矩阵自检，先回答三个问题：数据规模的天花板在哪（测点数 × 采集频率）？查询模式是什么（监控看板还是分析建模）？三年内要不要上 AI（问数、预测、Agent）？
Step 2：画能力基线
把需求翻译成可验证的指标：
-
写入吞吐：按峰值 × 2 留余量；
-
查询延迟：定 P99 目标，而不是平均值；
-
分析深度：列出未来半年要做的分析任务，逐项评估库内能否完成；
-
AI 融合：Agent、特征、知识库的规划；
-
三年 TCO：许可 + 硬件 + 人力 + 外挂组件的全部成本。
Step 3：POC 验证，按决策树走
先过写入关 （峰值吞吐 + 乱序数据），再过查询关 （用真实查询模式回放，不用理想化语句），最后过分析关（拿真实业务问题让产品当场实现）。分析关该问哪五个具体问题，上一篇有完整清单，此处不重复。
四个最常见的踩坑
-
**只看榜单和跑分。**榜单环境是理想化的，你的场景不是。
-
**只测写入不测分析。**写入是最容易达标的部分，分析能力才是两年后的分水岭。
-
**低估外挂链路的 TCO。**数据库省下的钱，会花在流引擎、分析平台、向量库和胶水代码的运维上。
-
**不留 AI 余量。**2026 年选型只看存储指标，等于给三年后的 AI 落地挖坑。
五、结论：选型选的是未来三年的数据架构
回到开头的问题：时序数据库是什么？它是围绕"高频写入、按时间聚合"重新设计的数据库。但 2026 年的答案正在变长------它还是实时计算的引擎、复杂分析的中枢，以及 AI 落地工业的数据底座。
选型的本质逻辑从未变过：**场景决定能力优先级，能力决定产品。**监控告警为主，监控指标系足够；常规存储与查询，时序专用系和关系扩展系成熟稳妥；而当场景走向千万测点、秒级预警、多源联合分析和 AI 问数，计算与智能能力就成了第一维度。
在这个维度上，DolphinDB 展示了国产时序数据库的另一种可能：存算一体架构下"千万级测点/秒写入、毫秒级查询、秒级复杂分析"的实时计算能力，2000+ 优化函数构成的全栈分析能力，以及 DolphinX、FeatureDB 带来的企业级 Agent 与智能分析能力------从高性能时序数据库，进化为面向 AI 时代的智能数据库 与工业数据库。长江电力、中广核、中科院、中国航天在生产环境的长期使用，是这套能力最硬的背书。
对工业物联网的选型决策者来说，2026 年选的不只是一个库，而是未来三年的数据架构路线。选"存得下"的，两年后可能要推倒重构；选"算得动、还能陪企业走进 AI 时代"的，才是一次真正的选对。
你的场景属于哪一类？欢迎在评论区聊聊你的选型纠结。