MySQL 資料類型完整指南：選型策略、儲存空間與效能考量

MySQL 資料類型選型：空間、效能與精度的平衡藝術

合理的資料類型選擇能節省 30-50% 儲存空間、提升索引效能、減少 I/O。本文系統整理數值、日期時間、字串、枚舉/集合四大類型的選型原則與實戰建議。

一、數值類型

整數類型 (精確、索引友善)

選型原則

1. 夠用就好： 每欄位省 1 位元組，千萬列省 10 MB，億級省 100 MB
2. 無號優先： ID、計數、關聯鍵皆非負，UNSIGNED 翻倍正向範圍
3. AUTO_INCREMENT 配合： 預估最大行數選最小型別

定點數：DECIMAL / NUMERIC (精確貨幣)

• 以字串形式儲存，每位數 1 位元組 + 小數點 1 位元組
• DECIMAL(10,2) 佔 12 位元組，範圍 -99999999.99 ~ 99999999.99
• 價格、金額、費率、比例 必須用 DECIMAL，禁止 FLOAT/DOUBLE

浮點數：FLOAT / DOUBLE (科學計算)

民用系統極少需求，謹慎使用。

二、日期時間類型

關鍵差異

• TIMESTAMP：儲存 UTC，讀取轉換為連線時區，ON UPDATE CURRENT_TIMESTAMP 自動更新
• DATETIME：字面值儲存，不做時區轉換，範圍更大
• 5.6.4+ 兩者支援小數秒 DATETIME(3)、TIMESTAMP(3)

三、字串類型

定長 vs 變長

選型決策

• 長度固定且接近上限 → CHAR (避免 1 位元組前綴開銷)
• 長度變化大、平均遠小於上限 → VARCHAR
• VARCHAR(255) 臨界點：超過 255 字元長度前綴變 2 位元組

大物件類型 (BLOB/TEXT 族)

最佳實務： 大物件拆分至獨立表 (垂直分表)，主表僅存檔案路徑/雲端 URL，避免主表膨脹影響掃描效能。

四、枚舉與集合

ENUM 實戰優勢

-- 性別欄位
`gender` ENUM('male','female','other') NOT NULL DEFAULT 'other'

-- 插入
INSERT INTO users (gender) VALUES ('male');  -- 字串寫入，內部存 1

-- 查詢
SELECT * FROM users WHERE gender = 'female'; -- 索引查詢極快

-- 排序按定義順序，非字母順
ORDER BY gender;  -- male(1), female(2), other(3)

五、選型檢查清單 (Code Review 用)

1. ID 欄位是否 UNSIGNED？
2. 金額欄位是否 DECIMAL(p,2)？
3. 定長代碼是否用 CHAR？
4. 狀態/分類是否用 ENUM？
5. 大文本是否垂直分表？
6. 時區敏感欄位是否用 TIMESTAMP？
7. 索引欄位長度是否最小化 (前綴索引)？

資料類型是 Schema 設計的地基。每次建表前花 5 分鐘思考類型選擇，上線後能省下數倍的調優成本。