MySQL DATETIME vs TIMESTAMP：儲存機制、時區行為與效能對決

儲存機制本質不同

• DATETIME：以 YYYY-MM-DD HH:MM:SS 字面值形式儲存，佔 5 Bytes (5.6.4 前) 或 8 Bytes (含微秒)，不進行任何時區轉換。
• TIMESTAMP：內部儲存為自 1970-01-01 00:00:00 UTC 起的秒數 (4 Bytes)，寫入時將會話時區轉為 UTC，讀取時再轉回會話時區。

時區敏感性實測

CREATE TABLE tz_test (dt DATETIME, ts TIMESTAMP);
SET time_zone = '+08:00';
INSERT INTO tz_test VALUES ('2024-06-15 12:00:00', '2024-06-15 12:00:00');
SET time_zone = '-05:00';
SELECT * FROM tz_test;
-- 結果：
-- dt: 2024-06-15 12:00:00  (不變)
-- ts: 2024-06-14 23:00:00  (變化！)

結論：跨時區應用、日誌審計、歷史資料歸檔 禁用 TIMESTAMP，改用 DATETIME 或應用層統一 UTC。

範圍與 2038 年問題

TIMESTAMP 受限於 32 位有號整數，上限為 2038-01-19 03:14:07 UTC。長期專案、金融、合規系統必須用 DATETIME (上限 9999 年) 或 BIGINT 毫秒時間戳。

自動初始化與更新

MySQL 5.6.5+ 兩者均支援：

CREATE TABLE t (
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    ts_created TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    ts_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

早期版本僅 TIMESTAMP 支援，且每表僅能有一個自動更新欄位；新版無此限制。

效能與空間對比

空間敏感場景 (如億級日誌表) 可考慮 TIMESTAMP，但需評估 2038 年風險。

最佳實踐總結

1. 業務時間、用戶可見時間、跨時區 → DATETIME (或 UTC BIGINT)。
2. 系統內部記錄、短期日誌、自動時間戳、確定不跨 2038 年 → TIMESTAMP。
3. 統一應用層時區為 UTC，資料庫層 SET time_zone = '+00:00'，消除轉換困擾。