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 也有这个问题。。。
timestamp查询范围问题
MySQL中timestamp类型日期，比如更新韶光是2020-05-26，查询是时 update_time <= 2020-05-26，是查询不到的，须要转为 DATE_FORMAT(info.up_time,'%Y-%m-%d') <= '2020-05-26',详细缘故原由不明，须要深入研究。
mysql timestamp比较查询 | 《Linux就该这么学》 (linuxprobe.com)
