mysql中timestamp比較查詢遇到的坑有哪些

這篇文章主要介紹mysql中timestamp比較查詢遇到的坑有哪些，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

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比較查詢遇到的坑有哪些”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！