MySQL 欄位型別選擇指南：從資料特性到效能優化的決策框架

前言

「直接把所有欄位定成 VARCHAR(255) 不就好了？」——這是許多初學者的直覺，但會帶來儲存浪費、查詢效能低落、排序錯誤、索引無法建立等連鎖問題。欄位型別選擇是資料庫設計的基石，影響儲存空間、I/O 效率、CPU 計算成本、索引可用性、排序語意、應用程式資料對應。本文建立一套從「資料特性分析」到「效能權衡決策」的系統化選型框架，協助您做出最適合業務場景的型別決策。

一、核心決策五大維度

二、數值型別選型決策樹

整數家族

黃金法則：UNSIGNED 除非必須存負數；AUTO_INCREMENT 欄位必加 UNSIGNED；不確定範圍時寧大勿小（ALTER TABLE 可擴大，縮小需確保資料不溢位）。

定點與浮點數

金額處理最佳實踐：DECIMAL(12,2) 儲存分為單位的整數（如 12345 代表 123.45），或 BIGINT 儲存最小貨幣單位（分/分），應用層負責格式化顯示。

三、字串型別選型決策樹

關鍵權衡：

• CHAR 定長優勢：無碎片、固定位移快速定位、ORDER BY 效能佳
• VARCHAR 節省空間，但頻繁 UPDATE 易產生碎片，需定期 OPTIMIZE TABLE
• 超過 255 字元無定長選項，必須用 VARCHAR/TEXT
• BINARY/VARBINARY 對應位元組語意，比較區分大小寫、無字元集轉換

四、日期時間型別選型

決策關鍵：

• 需時區感知 → TIMESTAMP（注意 2038 年問題）
• 不需時區、範圍超過 2038 → DATETIME
• 日期與時間可選分離 → DATE + TIME（允許 NULL 表示無時間）
• 不完整日期（僅年/年月） → MySQL 5.7+ 支援 0 月/日，或拆分 YEAR/MONTH/DAY 欄位

五、特殊型別：ENUM 與 SET

限制：成員列表修改需 ALTER TABLE，大量成員時 DDL 鎖表久；避免用於頻繁變動的分類體系。

六、效能與索引綜合建議

1. 定長優於變長：高頻查詢/排序/連線欄位優先 CHAR、INT、DATE
2. 越小越好：SMALLINT 足夠時勿用 INT；VARCHAR(40) 足夠時勿用 VARCHAR(255)
3. NOT NULL：省 1 bit 儲存、簡化查詢邏輯、允許索引（早期版本強制）
4. ENUM 替代字串：固定值集合欄位改用 ENUM 獲數值運算優勢
5. PROCEDURE ANALYSE()：SELECT * FROM tbl PROCEDURE ANALYSE(10,2000) 獲取型別建議
6. BLOB 策略：大物件獨立副表、合成雜湊索引（MD5()）、避免 SELECT * 拖回大欄位
7. OPTIMIZE TABLE：定期整理碎片，特別是含 VARCHAR/BLOB 的高頻寫入表

七、AUTO_INCREMENT 主鍵型別完整約束

CREATE TABLE t (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  ...
);

四大必要條件：整數型別 + 索引（PK/UNIQUE）+ NOT NULL（舊版強制）+ UNSIGNED（建議）。

八、常見反模式與修正

結語

欄位型別選擇沒有標準答案，只有「在特定業務約束下的最優解」。建立資料剖析 → 範圍量化 → 效能權衡 → 索引規劃 → 未來擴充評估的標準化決策流程，並善用 PROCEDURE ANALYSE()、EXPLAIN、壓力測試驗證選型，才能打造既節省資源又高效能的資料庫結構。記住：型別是契約，不只是容器——它定義了資料的語意邊界與操作規則。