InfluxDB 2.x 不支持 OFFSET/LIMIT 分页，必须用时间窗口或游标分页：时间窗口法靠 start/stop 移动范围并配合 limit()；游标法推荐 sort() + after() 组合，基于上一页最后记录的 _time 和 _value 构造严格大于条件。
InfluxDB 2.x 没有原生 OFFSET/LIMIT 分页语法
InfluxDB 2.x 的 Flux 查询语言不支持 SQL 风格的 OFFSET 和 LIMIT，强行模拟分页容易漏数据或重复——因为 Flux 的 limit() 是按流顺序截断，而时间序列数据天然无全局稳定排序（尤其跨 shard 或多 bucket 时）。真正可行的分页必须基于时间戳或 _value + _time 组合做游标（cursor-based pagination）。
用 start/stop + limit() 实现“时间窗口分页”
适用于按时间范围查询、且能接受“每页固定时长”的场景（比如每页查 1 小时数据）。关键不是跳过前 N 条，而是移动时间窗口：
-
start和stop必须显式指定，不能依赖默认值；否则limit(n)可能只返回部分结果 -
limit(n)作用在当前窗口内，不是全局第 N 条；若某窗口数据少于 n，就拿不满 - 下一页的
start应设为上一页最后一条记录的_time加 1ns（避免重复），但需确保该时间点有数据——更稳妥是用last()提取末条时间再偏移
from(bucket: "my-bucket") |> range(start: 2024-01-01T00:00:00Z, stop: 2024-01-01T01:00:00Z) |> filter(fn: (r) => r._measurement == "cpu") |> limit(n: 1000)
用 after() + sort() 做游标分页（推荐）
当需要严格“第 N 条起查 M 条”时，必须引入游标。Flux 不提供 OFFSET，但可通过 sort() + after() + limit() 组合逼近：
- 先对结果按
_time（升序）和_value（降序防并列）排序：|> sort(columns: ["_time", "_value"], desc: false) - 用上一页最后一条的
_time和_value构造游标条件：|> after(column: "_time", value: 2024-01-01T00:59:59.999Z) |> after(column: "_value", value: 87.3) -
after()是严格大于，所以游标必须来自真实存在的记录，不能手动生成 - Go 客户端调用时，把游标存成字符串传入下一次查询，避免浮点精度丢失
Go 客户端中处理分页响应的陷阱
influxdb-client-go 返回的 flux.Table 是按表结构组织的，不是扁平行列表。直接用 len(table.Record()) 判断是否满页会出错——因为一个 table 可能含多个 group key，Record() 返回的是所有组的记录合并结果。
立即学习“go语言免费学习笔记（深入）”；
- 务必用
table.GroupKey().String()区分不同 series，否则跨 metric 分页会混数据 - 游标值从
record.Time()和record.ValueByKey("_value")提取，注意ValueByKey返回interface{}，需类型断言为float64或int64 - 网络中断或超时后重试，必须带相同游标，否则可能跳过或重复；建议在 Go 层加幂等键（如
page_token + timestamp）缓存已处理记录
复杂点在于：Flux 的排序稳定性不保证，同一时间戳多条记录时，sort() 后顺序可能波动。如果业务强依赖严格序，得在 Go 层二次排序——别指望数据库端完全搞定。
