mysql timestamp比較查詢遇到的坑及解決

Posted on by

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’,具體原因不明，需要深入研究。

以上為個人經驗，希望能給大傢一個參考，也希望大傢多多支持WalkonNet。

推薦閱讀：