最近接了个物联网平台的项目，每天几亿条设备数据往里灌，原来的 MySQL 扛不住了，得换时序数据库。团队里有人推 InfluxDB，有人推 TDengine，吵了一周没结论。干脆两个都调研一遍，把数据摆出来对比。这篇就是调研过程和结论，给同样纠结的人参考。
时序数据库到底要解决什么问题
先把需求定位清楚，不然对比没意义。
时序数据有几个特点：写多读少、数据量爆炸式增长、查询大多是聚合分析（均值、最大值、按时间段分组）、对实时性要求高。传统关系型数据库在数据量上来之后，写入吞吐和聚合查询都会拉胯，索引也扛不住。时序数据库就是冲着这些痛点设计的------高写入吞吐、高压缩率、针对时间窗口的查询优化。
我们的场景是工业物联网，1000 台设备每秒上报一次，每条数据 20 个字段，算下来每秒 2 万条写入，峰值能到 5 万。数据保留半年，查询需求主要是看设备趋势图和异常检测。这个量级不算特别大，但 MySQL 已经顶不住了。
InfluxDB 现在是什么状态
InfluxDB 这两年变化很大，版本迭代路线调整了不少，先理清楚。
版本线有点乱
InfluxDB 目前有三个大版本线在并存：
- 1.x：已经 EOL（End of Life），官方不再维护，云服务也停了。还在用 1.x 的建议尽快迁移。
- 2.x：还在支持，但 Flux 查询语言已经标记为维护模式。2.x 用的是 TSM 存储引擎，单机为主。
- 3.x：当前主推版本，分 Core 和 Enterprise/Clustered 两档。Core 是单节点开源版，Enterprise 是分布式集群版。存储引擎换成了 Apache Parquet 列式格式，查询引擎用的是 Apache Arrow DataFusion。
InfluxData 官方已经明确，2026 年 9 月 15 日之后 Docker 的 latest 标签会指向 InfluxDB 3 Core。新项目直接上 3.x 没悬念。
3.x 的核心变化
最大的变化是存储引擎换成了 Parquet。Parquet 是列式存储格式，配合 DataFusion 查询引擎，聚合查询性能比 2.x 的 TSM 有明显提升。计算和存储做了分离，数据可以存在本地磁盘或者 S3 上，存储空间据官方说能压缩到原来的 1/4.5。
另一个大变化是 Flux 被砍了。Flux 是 InfluxDB 2.x 主推的查询语言，功能强大但学习曲线陡，社区接受度一直不高。3.x 不再支持 Flux，改用原生 SQL 和 InfluxQL。InfluxQL 是类似 SQL 的语法，从 1.x 时代就有，迁移成本低。如果你之前用了大量 Flux 脚本，迁到 3.x 得全改写成 SQL，这个工作量不小。
生态是 InfluxDB 的强项
Telegraf 采集 agent、Chronograf 可视化、Kapacitor 告警，这套 TICK 生态很成熟。Grafana 对 InfluxDB 的支持也是一等公民，数据源配置开箱即用。云服务方面，AWS 推出了 Amazon Timestream for InfluxDB，托管部署省心。社区文档和第三方教程也多，踩坑了基本都能搜到解决方案。
TDengine 的特点
TDengine 是涛思数据开发的国产时序数据库，这几年在物联网和工业领域用得越来越多。
SQL 语法，上手快
这是 TDengine 最大的优势之一。它用标准 SQL 做查询，SELECT avg(temperature) FROM devices WHERE ts > NOW() - 1h INTERVAL(5m) 这种语法，会 SQL 的人零学习成本。相比 InfluxDB 早期的 Flux 语言，门槛低太多了。
TDengine 还有一个"超级表"的概念，把同类设备的数据结构统一定义，每个设备一张子表，查询时可以跨子表做聚合。这个模型对物联网场景特别贴合------一千台同型号设备，结构一样但数据独立，超级表一层抽象就搞定了。
存储和压缩
TDengine 用列式存储加自适应压缩算法，针对不同数据类型用不同的压缩策略。整数用 Delta 编码，浮点数用专门的压缩算法，加上一二级压缩，整体压缩率能到 10:1 甚至更高。官方的 TSBS 性能测试里，TDengine 的压缩率比 InfluxDB 3 Core 高 2.3 到 25.8 倍。
说白了，同样一亿条数据，InfluxDB 存 10GB 的话，TDengine 可能只要 1GB。数据量大了之后，这个差距直接影响存储成本和查询速度------磁盘 I/O 少了，查询自然快。
集群版
TDengine 3.x 支持原生集群，开源版就能用。最新版本到 3.4.2.2（2026 年 7 月发布），加了联邦查询、虚拟表等特性，BI 工具集成也做了优化。集群部署是原生分布式的，不像 InfluxDB Core 只能单节点，要集群得买 Enterprise。
拉出来比一比
光说特点不够直观，直接上对比。
写入性能
这是时序数据库的核心指标。官方 TSBS 测试数据：100 台设备的场景下，TDengine OSS 写入速度约 1074 万点/秒，InfluxDB 3 Core 约 95 万点/秒，差距超过 10 倍。宁德时代（CATL）的内部测试也印证了这个结果------TDengine 92 万点/秒 vs InfluxDB 28 万点/秒，而且 TDengine 的硬件成本只有 InfluxDB 的 40%。
当然，benchmark 数据看看就好，实际场景取决于数据模式和硬件配置。但量级差距摆在那，TDengine 在写入吞吐上确实领先。
查询能力
InfluxDB 3 用 DataFusion 引擎支持 SQL，查询能力不弱，复杂聚合和 JOIN 都能做。TDengine 也支持 SQL，还内置了大量时序分析函数（连续查询、状态窗口、会话窗口等），对时序场景的查询优化更深入。
实测中，1 亿条记录的均值聚合查询，TDengine 约 0.06 秒，对比组需要近 67 秒。这个差距主要来自存储格式和索引设计的差异------TDengine 按设备和时间双重分区，聚合查询只扫描相关数据块，不用全表扫。
压缩率
前面说了，TDengine 的压缩率比 InfluxDB 高一个量级。对数据量大的场景（比如保留一年以上的历史数据），这个差距直接体现在存储成本上。InfluxDB 3 的 Parquet 格式比 2.x 的 TSM 已经进步不少，但跟 TDengine 的多级压缩比还是有差距。
部署复杂度
InfluxDB 3 Core 单节点部署很简单，一个二进制或者 Docker 容器就起来了，适合中小规模场景。但要上集群就得买 Enterprise 版，部署和运维复杂度上去了，成本也不低。
TDengine 开源版就支持集群，部署也不算复杂，三节点起步就能跑。不过 TDengine 的集群运维文档和社区经验相对少一些，遇到问题排查难度稍大。
社区生态
这一项 InfluxDB 明显占优。GitHub Star 数、第三方工具集成、社区教程数量，InfluxDB 都领先。Grafana 对两者都支持，但 InfluxDB 的数据源插件更成熟。TDengine 的生态在快速追赶，但毕竟起步晚，国际社区的认知度和文档完善度还有差距。国内场景的话，TDengine 的中文文档和社区支持反而更到位。
怎么选
聊了这么多，给个结论。
选 InfluxDB 的情况：团队技术栈偏国际化，习惯英文文档和社区；已经有 Telegraf + Grafana 的监控体系，不想换；数据量中等（单节点 Core 够用）；预算允许上 Enterprise 集群；需要跟 AWS 等云服务深度集成。
选 TDengine 的情况：物联网/工业场景，设备数量多、数据量大；对写入性能和压缩率敏感；团队习惯 SQL，不想学新查询语言；预算有限，需要开源集群方案；国内部署，需要本地化支持。
我们最后选了 TDengine。原因很直接：写入性能差距太大，压缩率又高一截，开源集群能满足需求，SQL 语法团队上手快。InfluxDB 3 的 Parquet 方向是对的，但 Core 单节点的限制对我们来说不够用，Enterprise 又超预算。如果场景是中小规模的监控告警，数据量没那么夸张，InfluxDB 3 Core 其实是个很省心的选择。
选型这事没有标准答案，把业务需求和数据规模摆出来，对着上面的维度逐项打分，分数高的那个就是答案。