| 這篇文章主要介紹了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',具體原因不明，需要深入研究。