mysql timestamp比較查詢

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

原文來自：