最近，我们遇到了 InfluxDB 的 GROUP BY time 的一个非常烦人的问题。事实证明，如果我们尝试聚合每 30 天的数据，InfluxDB 会按意想不到的时间桶聚合我们的数据。
例如以下查询：
SELECT COUNT(user_id) AS result FROM measurement1 WHERE time > '2017-12-31 23:59:59' AND time < '2019-01-01 23:59:59' GROUP BY time(30d) FILL(0);
然后我们得到以下响应（以毫秒为单位的纪元时间）：
time result
---- ------
1513728000000000000 0
1516320000000000000 0
1518912000000000000 0
1521504000000000000 0
1524096000000000000 0
1526688000000000000 0
1529280000000000000 0
1531872000000000000 0
1534464000000000000 4
1537056000000000000 1
1539648000000000000 0
1542240000000000000 0
1544832000000000000 0
好吧，将纪元时间转换为正常日期后，我们发现返回的时间间隔为 2017 年 20 月 12 日、2018 年 19 月 1 日到 18 年 12 月 15 日（每 30 天）。
据我了解，聚合点是由 influxdb 根据时间的第一个值（GROUP BY time(value)）预先定义的。它甚至在文档中被提及，但规模要小得多——“预设时间边界”。但是，这些示例处理的是分钟和 1 天的聚合，并且可以使用 offset 参数轻松修复，因为这些尺度的默认聚合间隔是在午夜。
这很酷，但在这里我们要处理多天。在我们的例子中，我们不能使用 offset 参数，因为我们无法知道 GROUP BY 返回的时间间隔。
是否有任何来源/公式/算法或任何东西可以帮助我们预测这些时间间隔，以便我们可以抵消它们？如果没有这样的事情，那么我们如何克服这个问题呢？
我猜这一切的原因是性能，但很奇怪他们的文档中没有提到这个问题，因为这不是一种直观的行为。
编辑：我想我发现了涌入如何确定这些时间间隔——它总是从 0 纪元时间开始。如果这是真的，那么我们可以在拍摄查询之前随意使用偏移量。我希望这将被添加到他们的文档中，因为这可以为其他人节省大量时间 + 它可以确认下一个版本中不会出现重大更改。