大數據量下，時間範圍查詢（WHERE time > XX）極其高頻。是用 INT 存 Unix 時間戳，還是原生 DATETIME？本文在 MySQL 5.1 + PHP 5.2 環境下，對四種表結構進行百萬級插入、更新、點查、範圍查實測，給出數據支撐的選型結論。
| 表名 | 時間型別 | 內容欄位 | 行長度 |
|---|---|---|---|
date_test | INT | VARCHAR(255) | 非定長 |
date_test2 | INT | CHAR(255) | 定長 |
date_test3 | DATETIME | VARCHAR(255) | 非定長 |
date_test4 | DATETIME | CHAR(255) | 定長 |
所有表主鍵 id INT AUTO_INCREMENT，引擎 InnoDB，插入 100 萬筆（分 200 批，每批 5000）。
| 操作 | date_test (INT+VARCHAR) | date_test2 (INT+CHAR) | date_test3 (DATETIME+VARCHAR) | date_test4 (DATETIME+CHAR) |
|---|---|---|---|---|
| 插入 100 萬 | 26.60 | 62.39 | 30.26 | 67.54 |
| 更新 100 筆 | 2.62 | 2.55 | 2.45 | 2.83 |
| 主鍵點查 100 筆 | 0.38 | 0.54 | 0.33 | 0.51 |
| 時間範圍查 10 筆 | 30.20 | 65.19 | 39.72 | 70.46 |
INT + VARCHAR 最快，CHAR 定長導致頁分裂與寫入放大，顯著拖慢。VARCHAR 略優於 CHAR（行較短，頁容納更多行）。INT 顯著優於 DATETIME（30s vs 40s，非定長情況），定長情況差距更大（65s vs 70s）。COUNT(*) 與實際行數微差（InnoDB 估算值），屬正常現象。INT 比較為單指令整數比較，CPU 極快DATETIME 內部為 8 字節結構體，比較涉及多欄位（年月日時分秒）邏輯INT 鍵值更緊湊，單頁容納更多條目，IO 更少| 場景 | 推薦型別 | 理由 |
|---|---|---|
| 高頻時間範圍查詢、大數據量、MySQL 5.1/5.5/5.6 | INT UNSIGNED (Unix Timestamp) | 比較最快、索引最緊湊、跨語言互通 |
| 需時區感知、應用層大量日期運算、MySQL 5.7+ | DATETIME / TIMESTAMP | 原生函數支援豐富、時區自動轉換 |
| 混合場景 | BIGINT 毫秒級時間戳 | 兼容精度與效能，避免 2038 年問題 |
UTC 時間戳寫入，展示層按用戶時區轉換在 MySQL 5.1 時代及大數據量範圍查詢場景下，INT 時間戳在插入、範圍查詼上均顯著優於 DATETIME。隨著版本演進（5.7+ DATETIME 優化、瞬間列、函數索引），差距已大幅縮小。選型應結合版本、業務時區需求、遷移成本綜合決策。
