MySQL 整數類型完整對比：TINYINT 到 BIGINT 範圍、儲存與選型指南

MySQL 整數類型完整對比：TINYINT 到 BIGINT 範圍、儲存與選型指南

整數類型是資料庫設計中最基礎、使用最頻繁的資料類型。正確選型不僅關乎儲存空間效率，更直接影響索引效能、網路傳輸與應用層數據映射。本文提供 MySQL 五大整數類型的完整規格對比、儲存機制解析與實戰選型決策樹。

一、五大整數類型核心規格對比表

二、關鍵技術細節深度解析

1. 顯示寬度 INT(N) 的誤區

• INT(11)、BIGINT(20) 中的數字**僅為顯示寬度提示**，**完全不影響儲存範圍、索引大小或運算精度**
• 應用層 ORM (如 Hibernate、MyBatis) 可能根據此寬度生成字段長度驗證，**建議遷移至應用層驗證，資料庫層不指定寬度**
• MySQL 8.0.17 起已棄用顯示寬度語法，未來版本將移除

2. 無符號 UNSIGNED 的雙刃劍

建議：主鍵 ID 僅在確定超過 21 億且應用層能妥善處理時才用 BIGINT UNSIGNED，否則優先 BIGINT (有符號)。

3. 運算溢位與類型提升規則

• 所有算術運算 (+、-、*) **內部以有符號 BIGINT 或 DOUBLE 進行**
• 兩個 INT 相乘若結果 > 21 億，**會自動提升為 BIGINT 運算**，但最終若插入 INT 欄位會截斷/報錯
• 位運算 (&、|、^, ~) **以 64 位無符號 BIGINT 進行**

三、浮點與定點類型補充對比

鐵律：**任何涉及金錢、精確比率的場景，嚴禁使用 FLOAT/DOUBLE，強制 DECIMAL(19,4) 或更高精度**。

四、實戰選型決策樹

1. 是否為主鍵/外鍵？
   • 是 → 評估未來 5-10 年數據量：< 2 億用 INT，2-42 億用 BIGINT，> 42 億用 BIGINT UNSIGNED + 應用層適配
   • 否 → 進入第 2 步
2. 業務語義範圍？
   • 0/1 狀態、性別、少量枚舉 → TINYINT UNSIGNED
   • 年齡、百分比、小字典 → SMALLINT UNSIGNED
   • 中等計數、顏色值、IPv4 → MEDIUMINT UNSIGNED
   • 通用計數、時間戳秒 → INT UNSIGNED
3. 是否參與 JOIN/比較？
   • 是 → **雙方類型、符號位、字符集必須 100% 一致**，否則索引失效
4. 是否涉及金額/精確計算？
   • 是 → DECIMAL(精度,標度)，整數部分預留足夠位數

五、常見反模式與修正

六、效能影響量化

• 儲存空間：BIGINT 索引比 INT 大 100%，B+ 樹層高可能增加 1 層，隨機 I/O 增加
• 緩存效率：InnoDB Buffer Pool 同等內存下，INT 主鍵能緩存 2 倍行數
• 網路傳輸：結果集傳輸量按字節計算，大表查詢 BIGINT 明顯增加帶寬
• CPU 運算：64 位運算在 32 位系統 (極少見) 较慢，現代 64 位 CPU 無差異

整數類型選型是資料庫設計的基石功夫。**「剛好夠用、語義清晰、類型一致」**是核心原則。建立團隊類型選型規範表，納入評審清單，從源頭避免因類型不當導致的擴容重構、效能退化與資料錯誤。