mysql timestamp比較查詢遇到的坑及解決
timestamp比較查詢遇到的坑
記得之前京東要求mysql建表的時候update_time 為timestamp,create_time為datetime。后來阿里的編碼規(guī)范里要求兩者都要是datetime類型的。
對于timestamp和datetime的區(qū)別好多地方都有介紹。有時在想為什么京東會要求update_time必須timestamp呢?難道是因為占用的空間少點?還是只有timestamp才能設置默認值(on update current_timestamp)?默認值datetime不是也可以設置么。后來百度了下,才知道 datetime支持設置默認值是在5.7的時候才支持的。京東這么要求可能之前使用的mysql版本過低,同時要求update_time 能自動更新的緣故吧。
現(xiàn)在在一家公司也是這么要求的 ,update_time設置為timestamp。結果遇到坑了。一同事發(fā)現(xiàn)很奇怪的問題:為什么date比較查詢沒有結果,而把日志里面打印的sql直接執(zhí)行卻能查詢到結果??為什么會出現(xiàn)這種不一致的情況,我之前也沒遇到過。解決問題嘛,總是讓人興奮的。
自己在本地試了下,確實是這樣的,打印的日志沒有問題,而正是日志‘迷惑'了我們,讓人覺得很奇怪??戳讼卤容^的字段 是 update_time, 正是timestamp類型的。經(jīng)過阿里規(guī)范熏陶過,敏銳的覺得應該是類型的問題。所以自己百度了下發(fā)現(xiàn)是時區(qū)的問題。在數(shù)據(jù)庫連接url后面加上serverTimezone=GMT%2B8 參數(shù)就行了。當然另一種方式就用datetime,這樣能避免很多坑。
為什么會出現(xiàn)這樣的問題?是因為應用服務器和mysql部署的服務器時區(qū)不一致導致的。這就是為什么我們看到的打印日志沒有問題,但是卻查詢不到結果的原因(日志中看到的時間是本機的時區(qū),但是當數(shù)據(jù)傳輸?shù)絤ysql服務器時,是另一個時區(qū)的時間)
mysql 的date 也有這個問題。。。
timestamp查詢范圍問題
MySQL中timestamp類型日期,比如更新時間是2020-05-26,查詢是時 update_time <= 2020-05-26,是查詢不到的,需要轉為 DATE_FORMAT(info.up_time,'%Y-%m-%d') <= '2020-05-26',具體原因不明,需要深入研究。
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。
相關文章
詳解在Windows環(huán)境下訪問linux虛擬機中MySQL數(shù)據(jù)庫
這篇文章主要介紹了如何Windows環(huán)境下訪問linux虛擬機中MySQL數(shù)據(jù)庫,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2019-04-04MySQL如何統(tǒng)計一個數(shù)據(jù)庫所有表的數(shù)據(jù)量
最近在做統(tǒng)計想查找一個數(shù)據(jù)庫里基本所有的表數(shù)據(jù)量,下面這篇文章主要給大家介紹了關于MySQL如何統(tǒng)計一個數(shù)據(jù)庫所有表的數(shù)據(jù)量的相關資料,文中通過示例代碼介紹的非常詳細,需要的朋友可以參考下2022-04-04MySQL日期格式化yyyy-mm-dd詳解(DATE_FORMAT()函數(shù))
MySQL提供了很多功能強大、方便易用的函數(shù),在進行數(shù)據(jù)庫管理以及數(shù)據(jù)的查詢和操作時,幫助我們提高對數(shù)據(jù)庫的管理效率,下面這篇文章主要給大家介紹了關于MySQL日期格式化yyyy-mm-dd(DATE_FORMAT()函數(shù))的相關資料,需要的朋友可以參考下2023-01-01MySQL 5.6 中TIMESTAMP with implicit DEFAULT value is deprecat
安裝mysql的時候出現(xiàn)TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details),可以參考下面的方法解決2015-08-08