tidb 对应时间点的数据在所在时间范围内查询不到

select floor(UNIX_TIMESTAMP(“2022-11-10 00:59:59.996”) * 1000)

放大就可以了,按照你的数据时间精度,必须 放大,你按这个重建下结构… 就应该可以了

有道理呀

分析步骤:

  1. SELECT * FROM employees PARTITION (p1) where 查看数据到底在哪一个分区,定位到是真的分区问题.
  2. 有可能浮点数精度问题。

感谢大佬们,特别是xfworld大佬的支持

大佬看起来是时区的原因导致分区落错的,八点前和八点后的分区不一样,建表的sql里面按照utc来的,查询的时候按照上海时间来的

@xfworld @我是咖啡哥 @裤衩儿飞上天 求救

image
要是UTC 您的这个时间戳是不是也得改改。

mongo的 时间类型会直接把时间转换成iso时间也就是UTC时间。所有的操作都必须关注下时间。不然怎么都操作不成功。

假如一:
对于UTC时间的时区?对于字符串类型的时间是不是会自动将时间 -8小时呢??。

select start_time from history_wti_alarm_test where start_time=‘2022-11-10 00:58:59.996’;

帮忙查询下这个数据能查询出来不??

select start_time from history_wti_alarm_test where start_time=‘2022-11-10 00:58:59.996’ 也查不出来

删除p42之后,可以查找到了

时间都是东八区,查询和展示都没问题吧。

数据库里面的是utc的时区

假如:您看到的时间和insert的时间都是insert时间。但是您在DDL创建表的时候使用了UNIX_TIMESTAMP.转换成了时间戳,就是数字。

ddl内的转换的时间戳从建表语句上的整型验证了是正确的utc时区转换的,现在怀疑insert有bug导致数据入错时区了。

这和现象删除了p42数据又回到了p43时区是吻合的,稍后我验证下其他分区上是否存在这个问题 :sneezing_face: 我快哭了

在每一个分区上都有这个问题

这就确定是时区的问题了。 业务问题说下???


您看下这个 有问题没??


我使用的也是UTC 的时间

大佬你好。我大概看了下tidb的源码,有不少地方时区采用的是system