Golang客户端写入InfluxDB后查询计数异常固定为20远低于预期

观测结果呈现极强的固定规律：每10分钟窗口计数固定为20、日总计数约2800（144个每日10分钟窗口 × 20条 = 2880，与统计值高度吻合）、写入全程返回200无报错，这类现象并非随机故障，所有特征均匹配InfluxDB的已知运行逻辑，可按优先级逐一排查：

最高概率的触发原因（占比90%以上） #

• 同序列下相同纳秒时间戳的自动覆盖机制
  InfluxDB存储引擎的单序列（由相同measurement、相同tag值集合构成的独立数据集合）唯一主键为纳秒精度时间戳：如果两条写入记录的tag值完全一致、时间戳精确到纳秒也完全相同，后写入的field值会直接覆盖前者，不会新增独立存储记录。
  对应你的场景：如果Golang客户端批量写入时，没有给每条业务记录绑定对应真实采集时刻的独立时间戳，而是循环生成数据时复用了批次启动时的固定时间点，且单批次内固定生成20个不同的时间值，那么哪怕百万级的写入请求全部返回200，超过99%的记录都会因为时间戳重复被覆盖，最终每个10分钟窗口下留存的唯一记录刚好就是20条，和当前查询结果完全匹配。
• 字段类型错配导致的序列强行归并
  如果写入逻辑中把本该作为field存储的业务值错误配置为tag，或者循环生成写入点时，所有未在WHERE条件中筛选的tag值（比如实例ID、链路标识等）全部生成成固定值，所有写入的记录会被归并到同一个序列下，触发上面的时间戳覆盖逻辑，最终留存的记录数远低于实际发送的量级。

需逐一核对的配置类问题 #

如果排除了写入端逻辑问题，再检查服务端的配置项：

• 写入与查询的Retention Policy路由错配
  如果客户端写入时显式指定了写入经过降采样的保留策略下，而查询时未指定目标RP，默认查询原始数据对应的RP，就会出现写入成功、但查询统计值远低于实际量级的情况，整个路由过程不会触发任何写入报错。
• 连续查询的自动写入覆盖
  如果当前measurement配置了定时运行的连续查询，将聚合后的结果写回同一张measurement的同序列下，原始数据达到保留周期被清理后，查询时看到的就只有聚合后的固定数量记录，与当前观测到的固定计数特征完全匹配。

10分钟快速验证方案 #

跳过聚合统计，直接拉取原始记录定位根因：
执行无聚合的原始查询，查看最近1小时的实际留存数据：

SELECT * FROM "measurement_metrics" WHERE ("account_id" = 'account_value' AND "endpoint" = 'endpoint_value') AND time >= now() - 1h LIMIT 200

查看返回结果的纳秒时间戳重复情况：

• 如果同一个时间戳下对应多条重复的记录结构，可直接确认是写入时未独立生成时间戳导致的覆盖问题；
• 如果原始记录的时间戳完全连续无重复，再继续排查RP路由、连续查询的配置问题。

内容的提问来源于stack exchange，提问作者jpgranier