MySQL 時間類型深度對比：TIMESTAMP vs DATETIME vs INT 選型指南
1. 三類型核心屬性對比
| 屬性 | INT (Unix Timestamp) | DATETIME | TIMESTAMP |
|---|
| 存儲字節 | 4 bytes | 8 bytes (5.6.4+ 支持微秒) | 4 bytes |
| 數值範圍 | 1970-01-01 ~ 2038-01-19 (32位有符號) | 1000-01-01 ~ 9999-12-31 | 1970-01-01 ~ 2038-01-19 |
| 時區處理 | 無（應用層自行轉換） | 無（存什麼取什麼，不轉換） | 自動轉換：存儲轉 UTC，讀取轉回會話時區 |
| 默認值 | 無 | 5.6.5+ 支持 CURRENT_TIMESTAMP | CURRENT_TIMESTAMP |
| 自動更新 | 無 | 5.6.5+ 支持 ON UPDATE | 自動更新為當前時間 |
| 可為 NULL | 是 | 是 | 是（但無實際意義） |
| 時間函數支持 | ❌ 不支持 | ✅ 完整支持 | ✅ 完整支持 |
| 索引/范圍查詢 | ✅ BETWEEN 極快 | ✅ 支持 | ✅ 支持 |
2. 選型決策樹
需要 2038 年後日期？ → DATETIME
需要時區自動轉換？ → TIMESTAMP
海量范圍查詢、極致性能？ → INT (應用層處理轉換)
記錄創建時間（不可變）？ → DATETIME DEFAULT CURRENT_TIMESTAMP
記錄最後修改時間（自動更新）？ → TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
3. 典型應用場景
| 場景 | 推薦類型 | DDL 示例 |
|---|
| 訂單創建時間（永不變） | DATETIME | created_at DATETIME DEFAULT CURRENT_TIMESTAMP |
| 用戶資料最後修改時間 | TIMESTAMP | updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP |
| 日誌表、埋點數據（億級、頻繁范圍查詢） | INT | log_time INT UNSIGNED NOT NULL |
| 歷史數據、生日、年份等長跨度 | DATETIME | birth_date DATETIME |
4. 避坑提醒
- TIMESTAMP 2038 年問題：32 位系統 2038-01-19 03:14:07 後溢出，長期項目慎用或規劃遷移 64 位/DATETIME。
- DATETIME 不做時區轉換：跨時區應用需應用層統一處理（推薦存 UTC）。
- INT 類型不可直接用時間函數：
DATE_FORMAT() 等失效，需 FROM_UNIXTIME() 轉換。
- 5.6.4 前 DATETIME 不支持微秒，5.6.4+ 可用
DATETIME(3) 存毫秒。
