三大型別核心差異

特性	INT (Unix Timestamp)	TIMESTAMP	DATETIME
儲存空間	4 bytes	4 bytes	8 bytes (5.6.4+ 支援微秒)
時區感知	無（應用層處理）	**有**（存儲轉 UTC，讀取轉回 session 時區）	無（原樣儲存）
支援範圍	1970~2038 (32位) / 更久 (64位)	1970-01-01 ~ 2038-01-19	1000-01-01 ~ 9999-12-31
可讀性	差（需轉換）	中（客戶端自動顯示）	佳（原生 Y-m-d H:i:s）
索引/排序效能	最快（整數比較）	中	較慢（8 bytes 比較）
預設值/自動更新	需應用層維護	支援 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP	5.6.5+ 支援同上

官方效能測試數據（MyISAM，1000 萬行）

-- 建表與載入耗時
DATETIME:  14111s  14010s  14369s  檔案 130MB
TIMESTAMP: 13888s  13887s  14122s  檔案 90MB
INT:       13270s  12970s  13496s  檔案 90MB

-- 全表掃描 COUNT (WHERE 範圍查詢)
DATETIME:  3.93s
TIMESTAMP: 9.87s  (內部時區轉換開銷)
INT:       15.12s (UNIX_TIMESTAMP() 函數逐行計算)
INT (預計算常數): 1.94s  -- WHERE datetime > 1800 AND datetime < 2100

關鍵洞見

• INT 最快：前提是**應用層預計算常數**，避免 SQL 端呼叫 UNIX_TIMESTAMP()。
• TIMESTAMP 慢於 DATETIME：時區轉換開銷大，且 2038 年問題限制長期使用。
• DATETIME 平衡較好：可讀性強、範圍廣、5.6.5+ 支援自動初始化/更新、8 bytes 空間換取通用性。

選型建議決策樹

1. **需要跨時區、長期儲存、原生可讀** → DATETIME（首選）。
2. **極致寫入/查詢效能、應用層統一用 Unix 時間戳、範圍在 2038 前** → INT (BIGINT)。
3. **舊系統相容、單時區、2038 年前** → TIMESTAMP（新專案不推薦）。

避坑指南

• 不要在 SQL 裡對 INT 時間欄位用 UNIX_TIMESTAMP() / FROM_UNIXTIME()，會導致全表掃描且極慢。
• TIMESTAMP 受 time_zone 系統變數影響，跨時區遷移/備份還原時極易產生時間偏移 Bug。
• MySQL 8.0 建議統一 DATETIME(6)（微秒精度）+ 應用層 UTC 存儲，查詢時按業務時區轉換顯示。