MySQL 數據類型選型指南：從存儲原理到實戰節省空間的藝術

核心原則：夠用就好，越小越快

數據類型決定磁盤占用、內存佔用、CPU 計算代價、索引大小、緩存命中率。選型口訣：整數優於浮點，定長優於變長（高填充率時），最小類型優於大類型，業務語義優於技術便利。

一、數值類型深度解析

1. 整數家族：精確、高效、首選

實戰節省：1600 萬行表主鍵用 MEDIUMINT UNSIGNED 代替 INT，節省 16MB 純數據 + 索放大節省，緩存能多裝數萬行。

2. 定點數：貨幣、金額的唯一正解

• DECIMAL(M,D) / NUMERIC(M,D)：字符串存儲，每位 1 字節 + 小數點/符號。精度絕不丟失，適合價格、金額、匯率、比率。
• 定義建議：DECIMAL(19,4) 覆蓋多數貨幣場景（萬億級、4 位小數）；DECIMAL(65,30) 科學計算高精度。
• ⚠️ 計算較慢（轉換為二進制運算），高頻聚合場景可考慮「分/厘」整數存儲（BIGINT 存分），應用層除 100 顯示。

3. 浮點數：科學計算專用，業務禁用

鐵律：任何涉及金額、庫存、計費的業務絕對禁止使用 FLOAT/DOUBLE。0.1 + 0.2 ≠ 0.3 會導致賬目不平。

二、日期時間類型：精度與範圍的權衡

選型策略：

• 需時區自動轉換 → TIMESTAMP（注意 2038 年問題）。
• 長期存儲、無時區需求 → DATETIME 或 DATETIME(6)。
• 僅日期/時間 → DATE/TIME 節省空間。

三、字符串類型：定長 vs 變長的數學賬

股票代碼實戰：CHAR 還是 VARCHAR？

• 上海 6 位、深圳 4 位（歷史），平均長度 5.2，最大 6。
• CHAR(6)：固定 6 字節，無前綴，索引緊湊，適合高頻 JOIN/排序。
• VARCHAR(6)：平均 6.2 字節（含 1 字節前綴），略大。
• 結論：高頻關聯鍵、長度接近固定 → CHAR 勝出。

四、特殊類型與新特性

• BIT(1)：單位位，MySQL 內部聚合為 TINYINT，適合布爾標誌位組合。
• JSON (5.7+)：二進制存儲，支持路徑查詢、索引 (虛擬列)、部分更新，替代 TEXT 存儲半結構化數據。
• ENUM/SET：內部映射整數，不推薦（DDL 修改值需重建表、移植性差、優化器統計不準），用 TINYINT + 應用層字典/Check 约束替代。
• SPATIAL (GIS)：POINT/POLYGON 等，空間索引 (R-Tree) 支持範圍/相鄰查詢。

五、建表決策清單

1. 業務是否需要小數精確？→ DECIMAL / 整數分單位。
2. 數值範圍上限？→ 選最小整數類型 + UNSIGNED。
3. 時間是否跨時區？→ TIMESTAMP / DATETIME + 應用層時區。
4. 字符串長度分佈？→ 抽樣統計平均/最大長度，決定 CHAR/VARCHAR/TEXT。
5. 是否高頻 JOIN/排序/分組？→ 窄列、定長、整數優先，建立覆蓋索引。
6. 預估 3 年增長量？→ 主鍵類型預留 10 倍空間（MEDIUMINT → INT → BIGINT）。

數據類型選型是 schema 設計的基因，決定了系統未來 3-5 年的存儲成本、查詢性能、擴展彈性。每次建表前花 10 分鐘算賬，能省下未來無數個夜晚的優化痛苦。