timestamp比較查詢遇到的坑

記得之前京東要求mysql建表的時候update_time 為timestamp，create_time為datetime。后來阿里的編碼規(guī)范里要求兩者都要是datetime類型的。

對于timestamp和datetime的區(qū)別好多地方都有介紹。有時在想為什么京東會要求update_time必須timestamp呢？難道是因為占用的空間少點？還是只有timestamp才能設(shè)置默認(rèn)值（on update current_timestamp）？默認(rèn)值datetime不是也可以設(shè)置么。后來百度了下，才知道 datetime支持設(shè)置默認(rèn)值是在5.7的時候才支持的。京東這么要求可能之前使用的mysql版本過低，同時要求update_time 能自動更新的緣故吧。

現(xiàn)在在一家公司也是這么要求的 ，update_time設(shè)置為timestamp。結(jié)果遇到坑了。一同事發(fā)現(xiàn)很奇怪的問題：為什么date比較查詢沒有結(jié)果，而把日志里面打印的sql直接執(zhí)行卻能查詢到結(jié)果？？為什么會出現(xiàn)這種不一致的情況，我之前也沒遇到過。解決問題嘛，總是讓人興奮的。

自己在本地試了下，確實是這樣的，打印的日志沒有問題，而正是日志‘迷惑'了我們，讓人覺得很奇怪。看了下比較的字段 是 update_time, 正是timestamp類型的。經(jīng)過阿里規(guī)范熏陶過，敏銳的覺得應(yīng)該是類型的問題。所以自己百度了下發(fā)現(xiàn)是時區(qū)的問題。在數(shù)據(jù)庫連接url后面加上serverTimezone=GMT%2B8 參數(shù)就行了。當(dāng)然另一種方式就用datetime，這樣能避免很多坑。

為什么會出現(xiàn)這樣的問題？是因為應(yīng)用服務(wù)器和mysql部署的服務(wù)器時區(qū)不一致導(dǎo)致的。這就是為什么我們看到的打印日志沒有問題，但是卻查詢不到結(jié)果的原因（日志中看到的時間是本機的時區(qū)，但是當(dāng)數(shù)據(jù)傳輸?shù)絤ysql服務(wù)器時，是另一個時區(qū)的時間）

mysql 的date 也有這個問題。。。

timestamp查詢范圍問題

MySQL中timestamp類型日期，比如更新時間是2020-05-26，查詢是時 update_time <= 2020-05-26，是查詢不到的，需要轉(zhuǎn)為 DATE_FORMAT(info.up_time,'%Y-%m-%d') <= '2020-05-26',具體原因不明，需要深入研究。

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論