挖掘机驾驶宝典

Appearance

从 MySQL 理解 InfluxDB ​

InfluxDB 不是把 MySQL 表加上时间字段后的数据库。两者在数据身份、索引、更新、保留和查询方式上采用不同假设。

概念对照 ​

MySQLInfluxDB 时序模型差异
DatabaseDatabase 或 Bucket，取决于版本Bucket 还包含 Retention 语义
TableMeasurement / InfluxDB 3 Table通常按指标类别组织，不按设备拆表
ColumnTag 或 FieldTag 是维度，Field 是观测值
RowPointPoint 必须围绕 Timestamp 表达
Primary KeySeries Identity + Timestamp 的时序身份不使用常规 AUTO_INCREMENT 主键
Secondary IndexTag/Series Index 或新引擎列式过滤不为任意 Field 照搬 B+ Tree 索引设计
DELETE通常按时间范围或条件删除高频随机删除不是核心路径
UPDATE重写相同 Point 或重新写入不适合频繁随机行修改

写入对照 ​

MySQL：

sql
INSERT INTO cpu_metric(host, region, usage_user, collected_at)
VALUES ('server01', 'cn-east', 23.5, '2026-08-20 08:00:00');

InfluxDB Line Protocol：

text
cpu,host=server01,region=cn-east usage_user=23.5 1787212800000000000

MySQL 的字符串列不会自动成为索引；InfluxDB 传统模型中的 Tag 会参与 Series Identity。字段放错位置不仅影响查询，还会改变存储和基数。

InfluxDB 3 SQL 入门 ​

sql
SELECT
    date_bin(INTERVAL '1 hour', time) AS hour,
    host,
    avg(usage_user) AS avg_usage
FROM cpu
WHERE time >= now() - INTERVAL '7 days'
  AND region = 'cn-east'
GROUP BY 1, host
ORDER BY 1, host;

虽然语法接近 SQL，但要保留时序习惯：

  • WHERE 优先包含明确时间范围。
  • 使用时间窗口函数而不是对原始点做无限范围分组。
  • Tag/维度用于过滤和分组，Field 用于聚合。
  • SQL JOIN 是否适合取决于 InfluxDB 3 产品与数据分布，不代表可以照搬 OLTP 模型。

迁移判断 ​

MySQL 中的数据是否适合迁入 InfluxDB
每秒产生的设备采样适合
主机和应用性能指标适合
订单、账户余额和库存不适合作为唯一主存储
设备基础信息通常仍放关系库，可按查询需要冗余部分维度
历史状态变化适合时序化保存，但当前状态可能另存
大段应用日志视检索需求而定，日志系统可能更合适

最常见的组合是 MySQL 保存业务事实和主数据，InfluxDB 保存随时间产生的观测值。两者通过业务 ID 或稳定维度关联，但不要求每次时序查询实时访问 MySQL。

参考资料 ​