MySQL 資料類型深度解析與建表選型實戰策略

合理選擇資料類型是資料庫設計的基石，直接影響儲存空間、查詢效能、索引大小與資料正確性。本文系統梳理 MySQL 核心資料類型，結合實戰場景給出選型決策樹與避坑指南。

數值類型：精準匹配範圍，拒絕浪費

整數家族

選型鐵律：「夠用就好，越小越好」。每行省 1 Byte，億級資料即省 100MB+ 儲存與索引空間，緩衝區命中率同步提升。盡量加 `UNSIGNED` 並明確 `NOT NULL`，除非業務真有負值需求。

定點數：金額、價格的唯一正解

DECIMAL(M, D) / NUMERIC：以字串形式儲存，每位數字佔 1 Byte，小數點固定，**運算不失真**。

• 價格、金額、匯率、比率 → **強制使用 DECIMAL(10,2) / DECIMAL(12,4) 等**
• 禁止使用 FLOAT/DOUBLE 儲存金錢（二進位浮點無法精確表示 0.1 等十進位小數）

浮點數：科學計算、近似值場景

日期時間類型：語義清晰，避免時區坑

避坑指南：

• **全系統統一使用 UTC** 寫入 DATETIME，應用層負責展示端轉換，資料庫層不依賴 `time_zone` 變數。
• TIMESTAMP 2038 年問題、時區變更導致歷史資料語義漂移，謹慎使用。
• MySQL 5.6.4+ 支援 `DATETIME(6)` 微秒精度，高併發唯一排序首選。

字串類型：長度固定用 CHAR，變長用 VARCHAR，大文本用 TEXT

CHAR vs VARCHAR 核心差異

實戰選型案例

• 股票代碼（6位數字/4位數字） → `CHAR(6)`：雖長度不一，但上海股票佔多數，`VARCHAR(6)` 平均佔 7 Bytes（含長度前綴），反而比 `CHAR(6)` 的 6 Bytes 大。
• 手機號 → `CHAR(11)`：固定 11 位，無需長度前綴。
• 用戶暱稱、商品標題 → `VARCHAR(50~100)`：長度變化大。
• MD5/SHA1 雜湊值 → `CHAR(32)` / `CHAR(40)`：固定長度十六進位字串。
• UUID → `CHAR(36)`（含連字號）或 `BINARY(16)`（更省空間、索引更快）。

TEXT 家族與 BLOB

**BLOB** 對應二進位資料（圖片、檔案流），儲存機制同 TEXT 但無字符集/排序規則。生產環境強烈建議：大物件存對象存儲（S3/OSS），資料庫只存 URL/路徑，避免備份還原、複制延遲、緩衝區污染。

枚舉與集合：特定場景的輕量選擇

• ENUM('A','B','C')：單選，最多 65,535 個值，1~2 Bytes。適合**極少變更、值集固定**的狀態欄位（性別、訂單狀態、支付方式）。缺點：新增值需 `ALTER TABLE` 鎖表、排序按定義順序而非字面意義、難以移植他種資料庫。
• SET('A','B','C')：多選，最多 64 個成員，1~8 Bytes。適合標籤、權限位掩碼。**同樣有 ALTER TABLE 與移植性問題**。

現代架構多改用 **TINYINT/SMALLINT + 應用層常數/字典表**，兼具效能與彈性。

JSON 型別（MySQL 5.7+）

原生 JSON 支援索引（虛擬欄位索引）、路徑查詢、部分更新。適合**結構半固定、頻繁變動、查詢模式多樣**的屬性（商品 SKU 屬性、用戶偏好設定、日誌上下文）。**不宜**替代核心關聯欄位。

建表選型決策清單

1. 業務語義是什麼？（金額→DECIMAL，ID→BIGINT，狀態→TINYINT，時間→DATETIME）
2. 值的範圍與分布？（選最小滿足範圍的類型）
3. 是否需精確計算？（金額禁用浮點）
4. 是否跨時區？（統一 UTC + DATETIME）
5. 長度是否固定？（固定短→CHAR，其餘→VARCHAR/TEXT）
6. 是否需索引？（大文本/JSON 不直接建全文索引，用虛擬欄位/全文索引）
7. 是否會頻繁 ALTER？（ENUM/SET 謹慎用）

資料類型選得對，效能優一半。將上述策略內化為團隊建表規範，配合 Code Review 機制，能從源頭避免 80% 的儲存與效能隱患。