我们提供安全,免费的手游软件下载!
在数据库管理中,时区和时间戳的处理十分重要,对于跨国业务更显得至关重要。以下是一次MySQL时间戳问题的解决思考过程。
上一次需求上线后,部分线上数据观测要留到11月初。这是一个税收相关的需求,已有功能的线上数据观察已经完成,还剩下部分只有在十一月初才可以观察。
之前把hive sql发给了mentor,结果hive sql里的pt居然写成了 20251011 ,搞得我一直没发现,一直以为查出数据集为空只是数据还没生成?。并且意外发生了,之前mentor是当天晚上7点左右就有了对应的数据而我突然想起忘了执行,现在晚上11点执行了好几次都没有数据生成,人麻了?。这时候告诉mentor除了打电话估计也没人响应了,所以只能死马当活马医。
发现数据平台标明了 表产出时间的描述 .
表产出时间是在T+1产出,今天产出昨天的数据 ,时间分区为当前国家首都时间 .
在Mysql数据库查到的任务拒绝或者通过时间都是11/2开头的,这是否有点不对。
由于之前的我很喜欢分析数据库表,并且之前听到mentor们讨论过数据库的时间字段是时间戳。
立马想起了时间戳有鬼。通过AI验证后发现确实如此: timestamp是会随着MySQL会话时区而自动变换查询的结果。
用timestamp是因为跨多个国家业务,所以使用timestamp来统一。不用datetime是因为datetime存在存储时的时区不一样,那么拿出来后的时区也不一样,也就是不统一啦,不统一对于之后线上bug确定这会更麻烦。
那么接下来问题就只剩 确认下当前的时区是否是北京时区,如果是北京时区那hive中的数据就能作为观察的数据了。
第一次尝试: SELECT @@session.time_zone;
发现返回给我的结果是SYSTEM?,实习生可没有那么多权限去访问线上服务器。
第二次尝试: SELECT @@global.time_zone;
还是SYSTEM。底层原理是当前会话并没有设置时区,所以也就是直接用的默认时区,即查了也没用?。
陷入困惑,回到题目。
突然想到Mysql中
select CURRENT_TIMESTAMEP
再和我们当前北京时间确定下不就行了吗?
当然上面是运气好的情况,不然24时区一一确定也够呛。
所以运气来了!正好是我电脑的时间。
目前的Mysql显示的税收相关时间为2024-11-02 06:21:38。
那么步骤如下:
嘿嘿!看了所有代码改动都没问题,司机照常出车完单!至少避免了P0 Bug。
让我复习了挺多的,但愿这次秋招来个人收了我吧。
不过上述内容都是出自于我对于hive数据库表描述没有理解出现偏差,pt字段的类型也是string,这个确实没法百分百确认,我还查了和我们国家相近的日本,发现pt字段也是1101,可能上次mentor查的时候是意外吧。
相关资讯
热门资讯