时间戳和MySQL的DateTime带来的线上BUG

由于团队规定服务端接口使用毫秒级时间戳,但某处使用DateTime存储,造成MySQL在存储时四舍五入导致时间比对失败。在BUG复现中,相同时间戳在数据库被转换并存储后,再次读取出现误差。经过定位,发现MySQL DateTime默认不存储毫秒,通过改为Datetime(3)解决了问题。
摘要由CSDN通过智能技术生成

时间戳和MySQL的DateTime带来的线上BUG

问题背景

团队规定:服务端对外接口无论是接收还是返回,对于时间都是要时间戳,且毫秒格式,内部数据库存储建议BIGINT,而有人用了DateTime,导致了线上一个对接业务出现了时间戳校验失败的BUG。

BUG复现

  1. 外部接口首先请求接口A(实现了幂等),传了一个毫秒级别的时间戳和其他业务参数,如1538284559999(北京时间2018-09-30 13:15:59.999),;
  2. 系统接收到参数后,将时间戳转换为Date类型,存入数据库;
  3. 外部接口再次调用接口A,传了相同的参数,包括时间戳1538284559999,返回错误,而非期望的幂等成功。

BUG定位

经过查看日志等工作,发现mysql在存储1538284559999时进行了四舍五入,成了2018-09-30 13:16:00,系统再次拿出该时间戳时就成了1538284560000,这!根本没法对比啊!
为什么呢?
为什么mysql会对毫米级时间戳进行四舍五入呢?正常来说,无论是DateTime还是Timestamp,都可以存储毫秒级别的时间,于是搜索了一番,查找到一个

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值