MySQL CHAR vs VARCHAR 完整對比：儲存機制、效能差異與選型策略

效能實測場景與選型建議

場景 1：MD5/SHA 雜湊值、UUID、固定代碼 (ISO 國家碼、貨幣碼)

首選 CHAR(32)/CHAR(36)/CHAR(3)。長度絕對固定，讀取最快，索引最緊湊，無碎片風險。

場景 2：用戶名、郵件、地址、文章標題、JSON 片段

首選 VARCHAR(適當長度)。長度變動大，節省空間顯著。設定合理上限 (如 VARCHAR(191) 適配 utf8mb4 索引前綴限制)。

場景 3：高頻更新的狀態欄位、計數器、標籤

傾向 CHAR(1)/CHAR(2) 或 TINYINT/ENUM。固定長度避免行遷移，減少碎片。極短字串 CHAR 開銷可接受。

場景 4：超長文本 (文章內容、日誌詳情)

使用 TEXT/MEDIUMTEXT/LONGTEXT。超過 64KB 避開 VARCHAR 行大小限制，利用溢出頁機制。

索引策略特殊考量

• CHAR 索引鍵值固定長度，B+Tree 分頁填充率穩定，範圍掃描極快。
• VARCHAR 索引鍵值變長，InnoDB 5.7+ 支援前綴壓縮，但長度變動大時易導致頁面分裂。
• 聯合索引前綴順序：將高選擇性、固定長度欄位 (CHAR) 置前，提升索引過濾效率。

常見誤區澄清

1. 誤區：「VARCHAR(255) 就好，反正不佔空間。」
   真相：過大的定義長度會增加排序緩衝區、臨時表記憶體佔用，影響 ORDER BY、GROUP BY 效能。
2. 誤區：「CHAR 比 VARCHAR 快。」
   真相：僅在固定長度、高頻更新、全表掃描比較時有優勢；變長資料用 CHAR 反而浪費空間與 I/O。
3. 誤區：「VARCHAR 不會產生碎片。」
   真相：頻繁更新導致長度增長時，極易觸發行遷移與頁面分裂，需定期 OPTIMIZE TABLE。

決策檢查清單

1. 資料長度是否固定？→ 固定用 CHAR，變動用 VARCHAR。
2. 平均長度 vs 最大長度比例？→ 接近 1 用 CHAR，差距大用 VARCHAR。
3. 更新頻率高且長度可能變化？→ CHAR 或數值型別替代。
4. 是否為索引欄位且高選擇性？→ 固定長度優先。
5. 字元集為 utf8mb4？→ 注意 VARCHAR(191) 索引前綴限制，CHAR 無此限制。

結語

沒有絕對的「更好」，只有「更適合」。理解底層儲存機制，結合業務讀寫模式、字元集、索引策略綜合評估，才能做出最優型別選擇。