MySQL 整數類型詳解：TINYINT、SMALLINT、INT、BIGINT 範圍、存儲、顯示寬度誤區全解析

四大整數類型對比表

關鍵誤區：INT(M) 中的 M 不是長度限制

CREATE TABLE t (
    id1 INT(3),
    id2 INT(11),
    id3 BIGINT(20)
);

• 存儲大小完全相同：INT(3)、INT(11) 皆佔 4 字節；BIGINT(20) 佔 8 字節。
• M 僅影響「ZEROFILL」時的顯示寬度：
  INSERT INTO t VALUES (5, 5, 5);
SELECT * FROM t; → 005 | 00000000005 | 00000000000000000005（需定義 ZEROFILL 才生效）。
• 不限制插入值範圍：INT(3) 仍可插入 2147483647，超出顯示寬度照常存儲，僅顯示時不補零。

有符號 vs 無符號

CREATE TABLE t (
    signed_int   INT,
    unsigned_int INT UNSIGNED
);
INSERT INTO t VALUES (-1, 4000000000);  -- unsigned 可存 40 億，signed 會溢出報錯

• UNSIGNED 將範圍正向擴展一倍，適合「絕不為負」的業務字段（ID、計數、時間戳）。
• 混合運算陷阱：SELECT unsigned_int - signed_int 會隱式轉為無符號，負數結果變巨大正數；建議統一使用有符號或在應用層處理。

選型決策樹

1. 值範圍 ≤ 255 → TINYINT UNSIGNED
2. 值範圍 ≤ 65,535 → SMALLINT UNSIGNED
3. 值範圍 ≤ 42 億 → INT UNSIGNED（主鍵首選）
4. 值範圍 > 42 億 → BIGINT UNSIGNED
5. 需存負數 → 去掉 UNSIGNED

性能與空間影響

• 索引大小：主鍵/二級索引直接包含列值，BIGINT 索引佔用雙倍內存/磁盤，緩存命中率下降。
• CPU 運算：64 位整數運算比 32 位略慢，但在現代 CPU 差異微乎其微；首要優化點是縮小索引體積。
• 網絡傳輸：結果集攜帶 8 字節 vs 4 字節，高併發下累積頻寬差異可觀。

總結

「夠用就好，越小越好」。主鍵優先 INT UNSIGNED（42 億足夠 99% 業務），分布式 ID 才用 BIGINT。拒絕盲目 BIGINT(20)，理解 M 僅為顯示提示，不影響存儲與範圍。