InfluxDB 1.x中查Measurement总条数需用SELECT COUNT() FROM "mymeas" GROUP BY ，返回单行或多行count_value；Go客户端须遍历Values提取float64再转int64，注意空响应和类型断言；2.x则须用Flux配合group(columns: [])和sum()。
用InfluxQL的COUNT(*)查单个Measurement总条数
InfluxDB 1.x 不支持直接 SELECT COUNT(*) FROM "mymeas" 返回一个数字——它会返回带时间戳的行，每行对应一个时间分组。必须加 GROUP BY time(1d) 或显式用 GROUP BY * 才能聚合，但那样结果还是多行。真正要总数，得靠子查询或客户端侧累加。
最稳妥的做法是用 InfluxQL 发起带 GROUP BY * 的聚合查询，再在 Go 里遍历响应行求和：
SELECT COUNT(*) FROM "cpu" GROUP BY *
这个语句会把所有 tag 组合视为一组，最终只返回一行（前提是数据有相同 tag 组合），count_value 字段就是总数。如果 tag 组合不唯一（比如同时有 host=A 和 host=B），就会返回多行，此时需要在 Go 中 sum 所有 count_value 值。
Go 客户端执行查询并提取COUNT结果
InfluxDB 官方 Go client（influxdb1-client）返回的是 *client.Response，结构嵌套深，字段名依赖 schema。关键点：结果在 response.Results[0].Series[0].Values，每行是 []interface{}，顺序固定为 [time, count_value]（当只有 COUNT 聚合时）。
立即学习“go语言免费学习笔记（深入）”；
- 务必检查
response.Err和len(response.Results)，空响应不报错但Series可能为 nil -
Values里的count_value是float64类型，即使计数是整数，也要用int64(v.(float64))转换 - 如果
Series为空（比如 Measurement 不存在或没数据），直接 panic 或返回 0，别假设有默认值
InfluxDB 2.x 用户注意：Flux 语法完全不同
如果你连的是 InfluxDB 2.x，InfluxQL 不可用，必须用 Flux。查总数不能写 count() 就完事——它默认按 _value 分组，得显式取消分组：
from(bucket: "mybucket") |> range(start: -30d) |> filter(fn: (r) => r._measurement == "cpu") |> count() |> group(columns: []) |> sum(column: "count")
这段 Flux 的作用是：先过滤出 measurement，再统计总数，然后去掉所有分组（group(columns: [])），最后用 sum() 把可能的多行合并成单个数值。少任何一步，Go 客户端收到的都可能是多行或结构异常的结果。
用 Go 调 Flux 查询时，返回的是 CSV 格式流，需用 influxdb2.NewClient().QueryAPI(...).Query() 迭代 flux.Table，从 Record.ValueByKey("count") 提取值，不是 JSON 字段名。
性能与边界情况：大数据量下别硬 COUNT(*)
当 Measurement 有上亿条记录时，COUNT(*) 会扫描全表，可能超时或 OOM。InfluxDB 不支持索引加速 COUNT，也没类似 MySQL 的元数据表可查。
- 如果只要“大概数量”，可估算：查最近 1 小时条数 × 24 × 天数，前提是写入速率稳定
- 如果高频统计，建议在写入端用 Redis 或本地计数器维护近似总数，定期对账
- InfluxDB 1.x 的
SHOW SERIES CARDINALITY ON "mydb"只能查 series 数量，不是 record 总数，别混淆
真正要精确总数，就老老实实发 COUNT 查询——但得准备好处理空响应、类型断言失败、以及 Flux 返回空表却无错误这类静默失败场景。
