資料庫字串類型大比拚：CHAR、VARCHAR、TEXT 與 Unicode 系列深度解析

字串類型選擇不當的隱形成本

資料庫設計時，字串類型常被忽視。隨著儲存成本降低，開發者傾向「大而全」的 VARCHAR/TEXT，卻忽略了索引效能、儲存空間、字元集相容性的深層影響。本文系統梳理六大類型差異，建立正確選型觀念。

核心類型對照表

關鍵差異深度解析

1. CHAR vs VARCHAR：經典權衡

• 空間： VARCHAR 只佔實際長度+1/2 bytes；CHAR 永遠佔 n 字元空間。
• 速度： CHAR 固定偏移量，索引查找、全表掃描更快；VARCHAR 需讀取長度前綴，略慢。
• 碎片： VARCHAR 更新導致行長度變化，易產生碎片；CHAR 不會。
• 建議： 長度固定且短（<50）用 CHAR；長度變動大或>50 用 VARCHAR。

2. TEXT/BLOB 的特殊限制

• 無法設定 DEFAULT 值（MySQL 8.0 前）。
• 索引必須指定前綴長度（如 `INDEX idx_content (content(100))`），無法全文索引全文。
• 查詢常產生臨時表（Using temporary），影響效能。
• 儲存在溢位頁，讀取需額外 I/O。

3. Unicode 系列 (N-char) 的誕生背景

早期資料庫單字節字元集（Latin1/GBK）導致中英文混存亂碼。Unicode (UCS-2/UTF-16) 以固定 2 bytes 編碼所有字元解決相容性問題。

• 優勢： 不分中英文，長度即字元數，應用層無需處理字元集轉換。
• 劣勢： 純英文/數字場景佔用雙倍空間（CHAR/VARCHAR 可存 8000 英文，NCHAR/NVARCHAR 僅 4000）。

選型決策速查表

最佳實踐原則

1. 夠用就好：長度設定業務實際上限，避免 VARCHAR(255) 濫用。
2. 統一字元集：資料庫、表、欄位、連接全鏈路統一 UTF8MB4，拒絕隱式轉換。
3. 索引前綴長度：TEXT/BLOB/VARCHAR(>255) 建索引必須指定前綴，長度覆蓋 90%+ 唯一值即可。
4. 避免 SELECT *：含 TEXT/BLOB 欄位會觸發額外 I/O。