这篇文章主要介绍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 <= 2020-05-26，是查询不到的，需要转为 DATE_FORMAT(info.up_time,'%Y-%m-%d') <= '2020-05-26',具体原因不明，需要深入研究。
以上是“mysql中timestamp比较查询遇到的坑有哪些”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
