influxdb 2.x中数学运算必须用flux的map()函数实现，字段需同measurement/tag且时间对齐，整型须显式转float；1.x中influxql支持select内四则运算但要求字段同series且双引号包裹字段名。
在InfluxDB 2.x中用Flux执行加减乘除运算
InfluxDB 2.x 不再支持类SQL的 SELECT a + b FROM ... 写法，所有数学运算必须通过 Flux 脚本完成。直接写算术表达式会报错 invalid identifier 或 cannot use + with series —— 因为 Flux 是按列（column）和流（stream）处理数据的，不是按行。
常见场景：把两个字段相加（如 cpu_usage_user + cpu_usage_system）、对字段做缩放（如把毫秒转秒）、计算百分比、或做差值比较。
- 所有算术操作必须放在
map()函数里，且只能作用于当前 record 的字段值（r._value或r.field_name） - 如果要对多个字段做运算，它们必须在同一 measurement + tag 组合下、时间戳对齐（否则
join()或aggregateWindow()后再map()） - 注意字段类型：InfluxDB 默认把数字存为 float64，但若原始数据是 int，
r.field_name可能是 int 类型，此时r.a + r.b会失败，需显式转成 float：float(v: r.a) + float(v: r.b)
from(bucket: "my-bucket")
|> range(start: -1h)
|> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage_user" or r._field == "usage_system")
|> pivot(rowKey: ["_time"], columnKey: ["_field"], valueColumn: "_value")
|> map(fn: (r) => ({
r with
total_cpu: float(v: r.usage_user) + float(v: r.usage_system)
})
)
在InfluxDB 1.x中用InfluxQL做简单四则运算
InfluxQL 支持基础算术，但仅限于 SELECT 子句中的字段或常量，且要求参与运算的字段必须来自同一 series（即相同 measurement + tag set），不能跨 series 计算。
典型错误是试图 SELECT usage_user + usage_system FROM cpu 却没做 GROUP BY time(...) 或 WHERE 筛选，导致返回空结果或报错 expected field key —— 因为 InfluxQL 默认只返回一个字段，多字段需用 GROUP BY * 或明确限定 tag。
- 字段名必须用双引号包裹，尤其含下划线或大小写混合时：
"usage_user" + "usage_system" - 不支持函数嵌套运算（如
SIN("a") + COS("b")），仅支持+-*/% - 整数除法会截断小数（
5 / 2 = 2），需先乘 1.0 强制转浮点：("a" * 1.0) / "b"
SELECT "usage_user" + "usage_system" AS "total_cpu" FROM "cpu" WHERE time > now() - 1h GROUP BY time(10s), *
Go 客户端调用 Flux 执行运算的实操要点
用 Go 操作 InfluxDB 2.x 时，数学运算逻辑写在 Flux 脚本里，不是在 Go 代码里算。别在 Go 里取两批数据再循环相加——既慢又容易错失对齐时间点。
关键点在于：Flux 查询返回的是 [][]byte 行数据，Go SDK（influxdb-client-go）默认解析成 flux.Table 结构，字段名由 map() 中定义的别名决定（如上面的 total_cpu），不是原始字段名。
- 确保 Flux 脚本末尾有
|> yield(name: "result")，否则 Go SDK 可能收不到数据 - 用
queryAPI.Query()后，遍历Table时通过record.ValueByKey("total_cpu")取值，不是"usage_user" - 如果运算结果可能为 null（比如某时刻缺失一个字段），
ValueByKey()返回nil，需判空，否则 panic
为什么不用 Go 做后处理？
表面上看，在 Go 里读出 usage_user 和 usage_system 两列再 zip 相加更“可控”，但实际极易出错：时间戳微秒级不一致、采样频率不同、missing point 导致错位。Flux 的 pivot() + map() 天然按 _time 对齐，还支持 fill() 插值。
另一个坑是性能：10万点数据，Flux 在服务端 10ms 内完成，Go 客户端拉取+解析+对齐+计算可能耗几百毫秒，还占内存。
真正需要 Go 后处理的，只有 Flux 不支持的操作，比如自定义非线性函数、调外部 API、或写入前做业务校验——算术运算不在其中。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
