MySQL CHAR vs VARCHAR 深度對比：存儲機制、效能影響、碎片風險與選型建議

MySQL CHAR vs VARCHAR 深度對比：存儲機制、效能影響、碎片風險與選型建議

字符型佔數據庫 80%+，正確選型關鍵。本文從 MyISAM/InnoDB 存儲差異、長度分布、碎片、內存臨時表影響四個維度深度解析，給出四條具體選型原則。

存儲機制本質差異

四大選型原則

1. 短且長度固定/近似 → CHAR：如 MD5 (32)、UUID (36)、身份證 (18)、手機號 (11)、郵編 (6)。固定長度無碎片、無長度前綴、比較快。
2. 長度差異大、不固定 → VARCHAR：如地址、備註、文章內容。節省磁碟空間。
3. 極短列（1-2 字符） → CHAR：VARCHAR(1) 需 1 字節長度前綴，反而比 CHAR(1) 佔更多空間。
4. VARCHAR 定義長度不可貪大：VARCHAR(200) 存 10 字符，磁碟省但內存臨時表/排序按 200 字節分配，嚴重拖慢 ORDER BY、GROUP BY、UNION 使用臨時表的查詢。定義長度 = 業務最大長度 + 10% 冗餘。

碎片管理

• VARCHAR 頻繁更新長度增長 → 行遷移/碎片。定期 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 整理。
• InnoDB 頁分裂同樣產生碎片，innodb_fill_factor (默認 100) 可預留空間減少分裂。

效能實測提示