優化四大維度

1. 資料類型優化（本文重點）
2. 資料庫設計優化
3. SQL 查詢優化
4. 索引優化（最後詳述）

遇到效能瓶頸需從這四個維度系統調優，而非單點突破。

一、資料類型優化兩大原則

1. 越小越好：占用較少磁碟、記憶體、CPU 快取，處理週期更短。能用 TINYINT 別用 SMALLINT，能用 VARCHAR(10) 別用 VARCHAR(100)。
2. 越簡單越好：整數運算比字串比較快得多。

二、具體類型選型建議

1. 整數類型

TINYINT(1B) → SMALLINT(2B) → MEDIUMINT(3B) → INT(4B) → BIGINT(8B)
UNSIGNED 可擴展正數範圍（如 TINYINT UNSIGNED: 0~255）

2. 實數類型

• FLOAT/DOUBLE：非精確，CPU 硬體支援，速度快。
• DECIMAL：精確，適合金額。大數據量時可考慮 BIGINT 存儲「分/厘」整數（金額 × 100/10000）提升計算速度。

3. 字串類型

• CHAR：定長，尾部空格會被移除，適合極短固定長度（如 Y/N、MD5）。
• VARCHAR：變長，1-2 位元組儲存長度。VARCHAR(1000) 初插短值後更新長值易產生頁分裂碎片。
• 誤區澄清： VARCHAR(10) 與 VARCHAR(1000) 實際儲存空間相同，但後者排序、臨時表時消耗更多記憶體，故「越小越好」原則依然成立。

4. 大物件類型

• BLOB：二進制，無字符集/排序規則。
• TEXT：有字符集/排序規則。能用記事本開啟的存 TEXT，其餘存 BLOB。

5. 日期時間

• MySQL 最小粒度為秒（較粗）。
• TIMESTAMP：4 字節，儲存 1970 至今秒數，範圍至 2038 年，空間效率高。
• DATETIME：8 字節，儲存實際日期時間值，範圍更大。
• 系統需跨越 2038 年請用 DATETIME。

6. 主鍵選型

• 關聯欄位類型必須一致，否則隱式轉換導致索引失效。
• 主鍵首選整數（自增/雪花算法），避免 UUID/字串：

1. 插入效能差：無序導致索引頁分裂、隨機 IO。
2. 查詢慢：邏輯相鄰行物理分離。
3. 快取命中率低：緩存載入的物理相鄰頁邏輯不相鄰。