MySQL 中存儲時間的最佳實踐

平時開發中常常須要記錄時間，好比用於記錄某條記錄的建立時間以及修改時間。在數據庫中存儲時間的方式有不少種，好比 MySQL 自己就提供了日期類型，好比 DATETIME，TIMESTAMEP 等，咱們也能夠直接存儲時間戳爲 INT 類型，也有人直接將時間存儲爲字符串類型。

那麼到底哪一種存儲時間的方式更好呢？

不要使用字符串存儲時間類型

這是初學者很容易犯的錯誤，容易直接將字段設置爲 VARCHAR 類型，存儲"2021-01-01 00:00:00"這樣的字符串。固然這樣作的優勢是比較簡單，上手快。

可是極力不推薦這樣作，由於這樣作有兩個比較大的問題：

• 字符串佔用的空間大
• 這樣存儲的字段比較效率過低，只能逐個字符比較，沒法使用 MySQL 提供的日期API

MySQL 中的日期類型

MySQL 數據庫中常見的日期類型有 YEAR、DATE、TIME、DATETIME、TIMESTAMEP。由於通常都須要將日期精確到秒，其中比較合適的有DATETIME，TIMESTAMEP。

DATETIME

DATETIME 在數據庫中存儲的形式爲：YYYY-MM-DD HH:MM:SS，固定佔用 8 個字節。

從 MySQL 5.6 版本開始，DATETIME 類型支持毫秒，DATETIME(N) 中的 N 表示毫秒的精度。例如，DATETIME(6) 表示能夠存儲 6 位的毫秒值。

TIMESTAMEP

TIMESTAMP 實際存儲的內容爲‘1970-01-01 00:00:00’到如今的毫秒數。在 MySQL 中，因爲類型 TIMESTAMP 佔用 4 個字節，所以其存儲的時間上限只能到‘2038-01-19 03:14:07’。

從 MySQL 5.6 版本開始，類型 TIMESTAMP 也能支持毫秒。與 DATETIME 不一樣的是，若帶有毫秒時，類型 TIMESTAMP 佔用 7 個字節，而 DATETIME 不管是否存儲毫秒信息，都佔用 8 個字節。

類型 TIMESTAMP 最大的優勢是能夠帶有時區屬性，由於它本質上是從毫秒轉化而來。若是你的業務須要對應不一樣的國家時區，那麼類型 TIMESTAMP 是一種不錯的選擇。好比新聞類的業務，一般用戶想知道這篇新聞發佈時對應的本身國家時間，那麼 TIMESTAMP 是一種選擇。Timestamp 類型字段的值會隨着服務器時區的變化而變化，自動換算成相應的時間，說簡單點就是在不一樣時區，查詢到同一個條記錄此字段的值會不同。

TIMESTAMP 的性能問題

TIMESTAMP 還存在潛在的性能問題。

雖然從毫秒數轉換到類型 TIMESTAMP 自己須要的 CPU 指令並很少，這並不會帶來直接的性能問題。可是若是使用默認的操做系統時區，則每次經過時區計算時間時，要調用操做系統底層系統函數 __tz_convert()，而這個函數須要額外的加鎖操做，以確保這時操做系統時區沒有修改。因此，當大規模併發訪問時，因爲熱點資源競爭，會產生兩個問題：

• 性能不如 DATETIME：DATETIME 不存在時區轉化問題。
• 性能抖動：海量併發時，存在性能抖動問題。

爲了優化 TIMESTAMP 的使用，建議使用顯式的時區，而不是操做系統時區。好比在配置文件中顯示地設置時區，而不要使用系統時區：

[mysqld]

time_zone = "+08:00"

簡單總結一下這兩種數據類型的優缺點：

• DATETIME 沒有存儲的時間上限，而TIMESTAMP存儲的時間上限只能到‘2038-01-19 03:14:07’
• DATETIME 不帶時區屬性，須要前端或者服務端處理，可是僅從數據庫保存數據和讀取數據而言，性能更好
• TIMESTAMP 帶有時區屬性，可是每次須要經過時區計算時間，併發訪問時會有性能問題
• 存儲 DATETIME 比 TIMESTAMEP 多佔用一部分空間

數值型時間戳（INT）

不少時候，咱們也會使用 int 或者 bigint 類型的數值也就是時間戳來表示時間。

這種存儲方式的具備 Timestamp 類型的所具備一些優勢，而且使用它的進行日期排序以及對比等操做的效率會更高，跨系統也很方便，畢竟只是存放的數值。缺點也很明顯，就是數據的可讀性太差了，你沒法直觀的看到具體時間。

若是須要查看某個時間段內的數據

select * from t where created_at > UNIX_TIMESTAMP('2021-01-01 00:00:00');

DATETIME vs TIMESTAMP vs INT，怎麼選？

每種方式都有各自的優點，下面再對這三種方式作一個簡單的對比：

TIMESTAMP 與 INT 本質同樣，可是相比而言雖然 INT 對開發友好，可是對 DBA 以及數據分析人員不友好，可讀性差。因此《高性能 MySQL 》的做者推薦 TIMESTAMP 的緣由就是它的數值表示時間更加直觀。下面是原文：

至於時區問題，能夠由前端或者服務這裏作一次轉化，不必定非要在數據庫中解決。

總結

本文比較了幾種最常使用的存儲時間的方式，我最推薦的仍是 DATETIME。理由以下：

• TIMESTAMP 比數值型時間戳可讀性更好
• DATETIME 的存儲上限爲 9999-12-31 23:59:59，若是使用 TIMESTAMP，則 2038 年須要考慮解決方案
• DATETIME 因爲不須要時區轉換，因此性能比 TIMESTAMP 好
• 若是須要將時間存儲到毫秒，TIMESTAMP 要 7 個字節，和 DATETIME 8 字節差不太多

推薦閱讀

技術選型：爲何批處理咱們卻選擇了Flink

Redis 存儲對象信息是用 Hash 仍是 String