MySQL INTEGER 類型最佳實踐：儲存空間、範圍與選型指南

MySQL INTEGER 類型最佳實踐：儲存空間、範圍與選型指南

MySQL 提供多種整數類型（TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT），各自佔用空間與取值範圍不同。正確選型不僅能節省儲存空間，還能提升索引效能。本文彙整官方規格並給出實戰建議。

整數類型規格對照表

核心最佳實踐

1. 主鍵與自增 ID 必用 UNSIGNED

主鍵、外鍵、自增欄位永不為負，加上 UNSIGNED 可在相同空間下將正向範圍擴大一倍，且不增加儲存開銷。

id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY

2. BOOL/BOOLEAN 只是 TINYINT(1) 別名

• 儲存空間仍為 1 Byte，非 1 bit。
• 可儲存範圍同 TINYINT（-128~127），TRUE=1、FALSE=0，非零即真。
• 顯示時視為布林，實際運算仍是整數。

3. TINYINT(1) 括號內數字僅影響顯示寬度

TINYINT(1)、TINYINT(4) 儲存空間、範圍完全相同，括號內數字僅作為客戶端顯示寬度提示（如 ZEROFILL 填零），不限制實際存值。

4. 依業務上限選最小足夠類型

• 狀態碼、性別、布林旗標 → TINYINT UNSIGNED
• 年齡、小型字典表 ID → SMALLINT UNSIGNED
• 中型業務 ID、數量計數 → MEDIUMINT UNSIGNED 或 INT UNSIGNED
• 大型分散式系統全域 ID、時間戳毫秒 → BIGINT UNSIGNED

5. 避免在整數欄位加不必要的顯示寬度

INT(11) 與 INT 效能、儲存無差異，僅影響部分 GUI 工具顯示，建議直接寫 INT 保持簡潔。

選型決策樹

1. 是否可能為負？→ 是：SIGNED / 否：UNSIGNED
2. 最大值 ≤ 255？→ TINYINT
3. 最大值 ≤ 65,535？→ SMALLINT
4. 最大值 ≤ 16,777,215？→ MEDIUMINT
5. 最大值 ≤ 4.29 億？→ INT
6. 更大？→ BIGINT

合理選型是資料庫設計的基礎功夫，能從源頭減少磁碟 I/O、縮小索引體積、加快查詢速度。建議在建表腳本中明確標註 UNSIGNED，並以 CHECK 條件或應用層驗證確保資料不超界。