共计 953 个字符,预计需要花费 3 分钟才能阅读完成。
导读 | 这篇文章主要介绍了 mysql timestamp 比较查询遇到的坑及解决方案,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教 |
记得之前京东要求 mysql 建表的时候 update_time 为 timestamp,create_time 为 datetime。后来阿里的编码规范里要求两者都要是 datetime 类型的。
对于 timestamp 和 datetime 的区别好多地方都有介绍。有时在想为什么京东会要求 update_time 必须 timestamp 呢?难道是因为占用的空间少点?还是只有 timestamp 才能设置默认值(on update current_timestamp)?默认值 datetime 不是也可以设置么。后来百度了下,才知道 datetime 支持设置默认值是在 5.7 的时候才支持的。京东这么要求可能之前使用的 mysql 版本过低,同时要求 update_time 能自动更新的缘故吧。
现在在一家公司也是这么要求的,update_time 设置为 timestamp。结果遇到坑了。一同事发现很奇怪的问题:为什么 date 比较查询没有结果,而把日志里面打印的 sql 直接执行却能查询到结果??为什么会出现这种不一致的情况,我之前也没遇到过。解决问题嘛,总是让人兴奋的。
自己在本地试了下,确实是这样的,打印的日志没有问题,而正是日志‘迷惑 ’ 了我们,让人觉得很奇怪。看了下比较的字段 是 update_time, 正是 timestamp 类型的。经过阿里规范熏陶过,敏锐的觉得应该是类型的问题。所以自己百度了下发现是时区的问题。在数据库连接 url 后面加上 serverTimezone=GMT%2B8 参数就行了。当然另一种方式就用 datetime,这样能避免很多坑。
为什么会出现这样的问题?是因为应用服务器和 mysql 部署的服务器时区不一致导致的。这就是为什么我们看到的打印日志没有问题,但是却查询不到结果的原因(日志中看到的时间是本机的时区,但是当数据传输到 mysql 服务器时,是另一个时区的时间)
mysql 的 date 也有这个问题。。。
MySQL 中 timestamp 类型日期,比如更新时间是 2020-05-26,查询是时 update_time
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)