MySQL Datetime vs Timestamp 深度對比：選型避坑指南

MySQL Datetime vs Timestamp 深度對比：選型避坑指南

MySQL 中 DATE、DATETIME、TIMESTAMP 三大時間型別（加上 INT 存儲時間戳共四種）常讓開發者困惑。本文從儲存範圍、時區行為、自動更新、空間佔用、精度五個維度深度對比，助您根據業務場景做出正確選型。

一、核心異同對比表

二、關鍵差異深度解析

1. 時區敏感性 —— TIMESTAMP 最大特徵

-- 建立測試表
CREATE TABLE tz_test (
    dt DATETIME,
    ts TIMESTAMP
);

-- 會話時區設為 UTC
SET time_zone = '+00:00';
INSERT INTO tz_test VALUES (NOW(), NOW());

-- 切換到 +08:00 時區
SET time_zone = '+08:00';
SELECT * FROM tz_test;
-- 結果：
-- dt: 2024-01-15 06:00:00  (不變，原樣儲存)
-- ts: 2024-01-15 14:00:00  (自動轉換為 +08:00 顯示)

陷阱：若應用部署在多時區環境，或資料庫遷移跨時區，TIMESTAMP 讀取值會隨時區變化而改變，DATETIME 保持不變。跨時區系統慎用 TIMESTAMP。

2. 2038 年問題 —— TIMESTAMP 硬傷

TIMESTAMP 內部用 32 位有符號整數存儲秒數，上限為 2038-01-19 03:14:07 UTC。長期運行系統（銀行、日誌、審計）必須使用 DATETIME 或 BIGINT。

3. 自動時間戳維護

CREATE TABLE auto_ts (
    id INT PRIMARY KEY,
    create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 插入時 create_time/update_time 自動填充當前時間
-- 更新行時 update_time 自動刷新
-- DATETIME 5.6.5+ 也支援此語法

4. 空間效率

TIMESTAMP (4 bytes) 比 DATETIME (8/5 bytes) 節省一半空間，百萬級資料表可節省數十 MB。但考慮 2038 年限制，通常不建議以此為主要選型理由。

三、時間字串格式規範

MySQL 接受寬鬆格式，但強烈建議統一使用標準格式：

• 標準：'2024-01-15 14:30:45' (ISO 8601)
• 危險簡寫：'24-1-15' 可能被誤解析
• 年份兩位數規則：00-69 → 2000-2069，70-99 → 1970-1999
• 無效格式：'13:16:5' 會被視為錯誤，存入零值並報警告

四、選型決策樹

1. 需跨時區、多時區部署、資料庫可能遷移 → DATETIME
2. 業務時間範圍超出 2038 年 → DATETIME 或 BIGINT (毫秒時間戳)
3. 需自動維護建立/更新時間、單時區環境、資料量極大 → TIMESTAMP
4. 僅需日期 → DATE
5. 高精度計量、日誌追蹤 → DATETIME(6) 或 BIGINT

五、最佳實踐建議

1. 統一用 DATETIME：除非明確需要時區轉換與自動更新，預設選 DATETIME，兼容性最好、無年份焦慮
2. 應用層處理時區：資料庫存儲 UTC 時間（DATETIME），應用層按用戶時區轉換顯示
3. 避免隱含轉換：SQL 中時間字串務必加引號，格式統一
4. 啟用 SQL_MODE：NO_ZERO_DATE,NO_ZERO_IN_DATE 禁止零值寫入

總結

DATETIME 是通用型選擇，TIMESTAMP 是特殊場景優化工具。理解時區轉換機制、2038 年限制、自動更新語法，能避開 90% 的時間型別坑。原則：業務時間用 DATETIME，系統時間戳可考慮 TIMESTAMP。