InfluxDb 时间范围查询总结

简介: 问题:数据查不出来,查询数据少了 8 小时 从 InfluxDB查询数据发现当前数据查不出来,分析发现少了 8 小时。 所以在查询语句中减去了 8 小时,虽然数据可以查出来了,但是 group by 时,显示的数据会多一天。

问题:数据查不出来,查询数据少了 8 小时

从 InfluxDB查询数据发现当前数据查不出来,分析发现少了 8 小时。 所以在查询语句中减去了 8 小时,虽然数据可以查出来了,但是 group by 时,显示的数据会多一天。

先了解一下时区有助于理解下面查询结果, RFC3339详细定义了互联网上日期/时间的偏移量表示:

2017-12-08T00:00:00.00Z
这个代表了UTC时间的2017年12月08日零时:

2017-12-08T00:08:00.00+08:00

东八区的本地时间比零时区的本地时间快了8个小时。
在后台管理系统上输入的是东八区时间。

查了一下代码是这么写的’2019-10-18T00:00:00Z’,这样比实际时间多了 8 小时。通常是把查询条件减去8 小时就大吉大利了:

SELECT count(user_id_val) FROM user_day where time >= '2019-10-18T00:00:00Z' and time < '2019-10-23T00:00:00Z' group by time(1d)
name: user_day
time count
---- -----
2019-10-18T00:00:00Z 7522
2019-10-19T00:00:00Z 7355
2019-10-20T00:00:00Z 7740
2019-10-21T00:00:00Z 5997
2019-10-22T00:00:00Z 5430
减去 8 小时候后查询的结果如下:

SELECT count(user_id_val) FROM user_day where time >= '2019-10-17T16:00:00Z' and time < '2019-10-22T16:00:00Z' group by time(1d)
name: user_day
time count
---- -----
2019-10-17T00:00:00Z 7641
2019-10-18T00:00:00Z 7522
2019-10-19T00:00:00Z 7355
2019-10-20T00:00:00Z 7740
2019-10-21T00:00:00Z 5997
2019-10-22T00:00:00Z 0
显示的结果中,最后一天没有数据,误以为错了,此处省略……… 最后一天显示 0,终于知道那个叫晕的小伙伴为什么把结果减了 1.这样只是把 显示 零的问题消除了,导致结果偏移了一天。 既然减去了8 小时显示结果中的日期也是少了 8 小时,加上就自然对了。 感觉这样不完美,压根就不想让这个多余的 0 出现。因为查询的调条件跨越了 8 小时导致查询的结果比预期的多了天。

下面是用东八区格式查询的数据与R3339 查询的结果一样。都是因为跨越了8 小时导致多查了一天:

SELECT count(user_id_val) FROM user_day where time >= '2019-10-18T00:00:00+08:00' and time < '2019-10-23T00:00:00+08:00' group by time(1d)
name: user_day
time count
---- -----
2019-10-17T00:00:00Z 7641
2019-10-18T00:00:00Z 7522
2019-10-19T00:00:00Z 7355
2019-10-20T00:00:00Z 7740
2019-10-21T00:00:00Z 5997
2019-10-22T00:00:00Z 0
找到了原因如何查询呢?那个叫晕的小伙伴提供了如下查询方式,influxddb 查询时指定时区。大吉大利!:

SELECT count(user_id_val) FROM user_day where time >= '2019-10-18T00:00:00+08:00' and time < '2019-10-23T00:00:00+08:00' group by time(1d) TZ('Asia/Shanghai')
name: user_day
time count
---- -----
2019-10-18T00:00:00+08:00 7641
2019-10-19T00:00:00+08:00 7522
2019-10-20T00:00:00+08:00 7355
2019-10-21T00:00:00+08:00 7740
2019-10-22T00:00:00+08:00 5997
本地时间只包括当前的时间,不包含任何时区信息。同一时刻,东八区的本地时间比零时区的本地时间快了8个小时。在不同时区之间交换时间数据,除了用纯数字的时间戳,还有一种更方便人类阅读的表示方式:标准时间的偏移量表示方法。

RFC3339详细定义了互联网上日期/时间的偏移量表示:

2017-12-08T00:00:00.00Z
这个代表了UTC时间的2017年12月08日零时:

2017-12-08T00:08:00.00+08:00
时区知识点
这个代表了同一时刻的,东八区北京时间(CST)表示的方法 上面两个时间的时间戳是等价的。两个的区别,就是在本地时间后面增加了时区信息。Z表示零时区。+08:00表示UTC时间增加8小时。 这种表示方式容易让人疑惑的点是从标准时间换算UTC时间。以CST转换UTC为例,没有看文档的情况下,根据 +08:00 的结尾,很容易根据直觉在本地时间再加上8小时。正确的计算方法是本地时间减去多增加的8小时。+08:00减去8小时才是UTC时间,-08:00加上8小时才是UTC时间。

目录
相关文章
|
时序数据库
influxDB时序数据库2.0FLUX查询语法使用记录
influxDB时序数据库2.0FLUX查询语法使用记录
|
NoSQL MongoDB
mongodb 分组查询、指定时间段查询
mongodb 分组查询、指定时间段查询
|
5月前
|
SQL 关系型数据库 MySQL
实时计算 Flink版产品使用合集之从MySQL同步数据到Doris时,历史数据时间字段显示为null,而增量数据部分的时间类型字段正常显示的原因是什么
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStreamAPI、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
3月前
|
存储 SQL 数据库
influxdb 连续查询使用总结
influxdb 连续查询使用总结
132 0
|
4月前
|
时序数据库
时序数据库工具grafana里的$timeFilter查询1个小时内的数据如何写查询条件
【6月更文挑战第24天】时序数据库工具grafana里的$timeFilter查询1个小时内的数据如何写查询条件
529 0
|
5月前
|
存储 数据挖掘 数据库
InfluxDB的连续查询与数据聚合技术详解
【4月更文挑战第30天】InfluxDB的连续查询(CQ)功能用于自动定时聚合时间序列数据,适用于数据降采样、实时分析和告警通知等场景。CQ使用InfluxQL编写,例如,每1小时对`cpu_usage`测量值计算主机的平均CPU使用率并存入`cpu_usage_hourly`。InfluxDB提供多种聚合函数如`MEAN()`, `MAX()`, 支持滑动窗口聚合等复杂操作,助力时间序列数据分析和趋势预测。通过CQ,用户能高效管理和利用时间序列数据信息。
|
5月前
|
SQL 消息中间件 关系型数据库
Flink查询问题之每秒入库到mysql数量很少如何解决
Apache Flink是由Apache软件基金会开发的开源流处理框架,其核心是用Java和Scala编写的分布式流数据流引擎。本合集提供有关Apache Flink相关技术、使用技巧和最佳实践的资源。
|
SQL Prometheus 监控
TiDB亿级数据亚秒响应查询Dashboard使用
TiDB亿级数据亚秒响应查询Dashboard使用
186 0
|
SQL 存储 监控
一小时入门时序数据库 influxDB
InfluxDB是一个由InfluxData开发的开源时序型数据。它由Go写成,着力于高性能地查询与存储时序型数据。InfluxDB被广泛应用于存储系统的监控数据,IoT行业的实时数据等场景。
374 0
|
关系型数据库 MySQL
MySQL 根据日期查询并统计数据
作者主页:https://www.couragesteak.com/
MySQL 根据日期查询并统计数据