产品特性与选型边界
时序数据通常具有持续追加、时间有序、按时间窗口读取、旧数据价值下降和聚合查询频繁等特点。InfluxDB 针对这些访问模式优化，而不是作为通用关系数据库替代品。
适合的场景
| 场景 | 数据特点 | 常见查询 |
|---|---|---|
| 基础设施监控 | 主机、容器和服务持续产生指标 | 最近一小时趋势、分位数、异常窗口 |
| IoT 与工业采集 | 设备按固定或事件频率上报 | 按设备、区域和时间聚合 |
| 应用指标 | Counter、Gauge、Histogram 等指标 | Rate、窗口聚合、告警判断 |
| 能源和环境监测 | 多传感器长期采样 | 降采样、同期对比和缺失检测 |
| 实时业务指标 | 持续追加且强调近期数据 | 最近值、时间窗口汇总 |
不适用或需要谨慎的场景
| 场景 | 原因 |
|---|---|
| 复杂 OLTP | 外键、任意更新、跨实体事务不是主要设计目标 |
| 高频删除和随机行修改 | 时序引擎更适合追加和按时间保留 |
| 大量临时 JOIN | 版本能力不同，数据模型通常要求写入时确定维度 |
| 把日志原文全部作为 Tag | 会扩大 Series/Cardinality 或 Schema，增加元数据成本 |
| 没有时间范围的全库扫描 | 数据量随时间增长，必须设计查询边界和保留策略 |
业务主数据通常仍保存在 MySQL/PostgreSQL 等系统，InfluxDB 保存可按时间重建或聚合的观测数据。设备名称、组织关系等维表是否冗余写入，要结合查询语言和 JOIN 能力设计。
版本选择问题
- 是维护既有 1.x/2.x，还是建设新的 InfluxDB 3 系统。
- 现有 Dashboard 和任务依赖 InfluxQL、Flux 还是 SQL。
- 需要单机开源版本、企业集群还是托管 Cloud。
- 数据保留期、写入量、查询窗口和恢复目标是什么。
- 是否依赖连续查询、Task、Plugin、Processing Engine 等版本专有能力。
迁移不是只替换 Endpoint。Bucket、Retention Policy、Database、Measurement/Table、认证 Token 和查询 API 的含义都可能发生变化。