數據庫存儲時間到底該用什么類型？
“yes，最近設計一個新項目的數據庫表結構，別的項目以前的表，發現這個時間字段類型都沒個統一，我有點麻了?！?/p>
老陳眨了眨他的瞇瞇眼，望向了我。
“是不是有用 int、有TIMESTAMP 還有 DATETIME 的？” 我早就發現了這個亂象，大家都各自設計各自的，沒個統一的類型。
“對對對，你說應該選哪個好？”
老陳又要給我送溫暖了，我趕緊回答道：“首先，這個 int 類型得先淘汰了，雖然從功能來說用 int 存儲時間戳沒毛病，不過最多就只能存到 2038 年，不過這也不知重點，今年才幾幾年，管那么多，指不定到時候項目都 G了。”
“重點是，int 用不了 DEFAULT CURRENT_TIMESTAMP? 和 ON UPDATE CURRENT_TIMESTAMP?！?/p>
當記錄插入的時候，如果沒有指定時間，那么默認填入當前時間。
當記錄修改時，自動更新時間，相當于自動修改記錄的更新時間，不需要人為塞值。
這兩個玩意就很好使了，非常方便，不然相關的 SQL 你都得顯示的寫入插入和修改當前時間的語句。
麻煩！且容易漏！編程這玩意最重要的是簡單、便捷，花里胡哨的都容易出錯。
老陳聽完，煞有其事地點了點頭，示意我繼續。
魚兒已經上鉤，我怎能輕易放過！
我故作停頓，瞟了眼他桌上的抗原檢測試劑，這玩意最近可是硬通貨，網上壓根買不著了。
老陳心領神會，雙手捧著一盒，輕輕地放在我的桌上。
我點了點頭，繼續說道：“至于 TIMESTAMP 的話，5.6版本以上支持 TIMESTAMP(N) N 表示秒的小數位，最高可達六位，不過它也只能存到 2038 年，本質上跟 int 一樣，都是時間戳，不過數據庫可以操作它進行時區的轉換！”
時間戳存的就是'1970-01-01 00:00:00' 到現在的毫秒數，沒有時區的概念，而 MySQL 的 TIMESTAMP 類型可以指定時區返回不同的時間。
簡單點，我拿 SELECT NOW() 來舉例不同時區的情況。
比如我現在不指定時區，默認就是操作系統的時區，返回的結果如下圖所示：
然后我現在整個把時區變成卡塔爾的，你看看，時間是不是就變了？TIMESTAMP 就是有這樣的功效。
老陳定睛一看，冷不丁地冒出一句：“這丫的世界杯時間真不友好，老是在我們凌晨 3 點踢，你看看，熬的我都長痘痘了！破壞我英俊的臉龐！”
“話說回來，這時區功能不是必備的呀，我在服務端轉個時區不就得了嘛？”
我嫌棄地瞄了他一眼，忽略他的臭美：“沒錯，如果有分時區的需求，服務端直接轉時區塞給前端就行了，而且利用 MySQL 轉時區還有小坑！”
因為 TIMESTAMP 綁定了時區的屬性，所以每次都需要利用時區來計算時間，如果我們 MySQL 沒有指定時區，那么默認就需要每次查看操作系統的時區，就得調用操作系統底層的 __tz_convert 函數，會加鎖，而加鎖就意味著資源爭搶！
在高并發的時候，影響可能就會比較大了！
所以如果非要用 TIMESTAMP ，那么記得在 MySQL 配置文件中顯示設置時區！
“OKOK，那我就不用 int 也不用 TIMESTAMP ，就用 DATETIME 了！不會這玩意也不好使吧？”
我搓了搓手，又瞄向了他桌上剛收到的快遞，看這包裝好像是 KN95 口罩？
老陳順著我的目光，心疼地移步向前拆開包裝扔給了我一包，罵罵咧咧道：“這狗日的口罩，現在不僅難買還很貴，這玩意前不久還 1 塊錢，現在要 5 塊！真是些黑心商家！”
“可不嘛，我在網上下了十幾單，漲價我忍了，還都是預售的！發貨時間1-45天內....”我吐槽道，“行了，不扯這個，繼續說 DATETIME?！?/p>
DATETIME 沒有 2038 的限制，可以存到 9999-12-31 23:59:59?，也沒有時區屬性，并且支持 DEFAULT CURRENT_TIMESTAMP? 和 ON UPDATE CURRENT_TIMESTAMP。
DATETIME(N) 中的 N 表示秒的小數位，最高可達 6 位，也是 5.6 版本以上支持。
這個 N 可能光說你沒直觀的影響，我還是拿 SELECT NOW 舉個例子:
所以 DATETIME 其實沒啥缺點，如果非要說個的話可能就是空間的占用了相比會大些了，看下下面這個圖：
對了，上圖還有個 DATE 類型，這個就不說了，只能存儲日期，無法存儲時分秒。
老陳摸了摸他的大光頭，“懂了，問就是 DATETIME！”
孺子可教！
我埋頭理了理桌上的 KN95 和抗原，美滋滋：“果然知識就是金錢??！古人誠不欺我！”
更過故事，請聽下回分享！
