Oracle CHAR vs VARCHAR2 深度對比：存儲、性能與選型指南

Oracle 字符類型選型看似簡單，實則暗藏性能與存儲陷阱。本文從底層存儲機制、查詢性能、遷移兼容三個維度，徹底解析 CHAR 與 VARCHAR2 的區別，給出落地選型建議。

核心差異一覽表

性能迷思與實測

傳統認知：CHAR 查詢更快？

早期文檔稱「CHAR 定長，定位快；VARCHAR2 需解析長度，慢」。實測表明：

• 全表掃描：CHAR 因佔用更多空間，I/O 更多，反而更慢。
• 索引範圍掃描：CHAR 固定長度利於 B-Tree 頁面填充因子穩定，極少數場景略快（< 1%）。
• 結合查詢：CHAR 空格填充語義導致隱式轉換，可能使索引失效，反而拖慢性能。

結論：現代 Oracle（10g+）優化器對 VARCHAR2 高度優化，**性能差異可忽略**，存儲空間與語義正確性才是決策關鍵。

遷移與兼容性陷阱

1. Oracle 內部：SYS 系統表大量使用 CHAR，歷史包袱，**用戶表勿效仿**。
2. 其他數據庫：
   • MySQL：CHAR 同 Oracle，VARCHAR 等同 VARCHAR2。
   • PostgreSQL：CHAR(n) 固定長度，VARCHAR(n) 變長，無 VARCHAR2。
   • SQL Server：CHAR/NCHAR 固定，VARCHAR/NVARCHAR 變長。
3. 應用層框架：Hibernate/JPA @Column(length=10) 默認映射 VARCHAR2，強制 CHAR 需 columnDefinition="CHAR(10)"。

選型決策樹

IF 長度極其固定（如 MD5=32, UUID=36, 國標代碼=6）AND 高頻 JOIN/索引
    → 考慮 CHAR(n)  // 極少數場景
ELSE IF 需要語義精確比較（尾部空格有意義）
    → VARCHAR2(n)   // CHAR 會自動補空格導致語義偏差
ELSE IF 存儲中文/多語言/可變長文本
    → VARCHAR2(n)   // 節省空間，語義直觀
ELSE
    → VARCHAR2(n)   // 默認首選

最佳實踐清單

1. 默認用 VARCHAR2：節省存儲、語義直觀、兼容性最好。
2. 定長代碼/雜湊值：可評估 CHAR，但需實測確認索引收益 > 空間浪費。
3. 避免隱式轉換：WHERE 子句比較時，確保參數類型與列類型一致，防止 CHAR 空格填充導致索引失效。
4. 數據遷移腳本：異構遷移時，CHAR → VARCHAR2 需 RTRIM 去除尾部空格，防止業務邏輯誤判。
5. 12c+ 開啟 EXTENDED：ALTER SYSTEM SET MAX_STRING_SIZE=EXTENDED SCOPE=SPFILE，突破 4000 字節限制。

字符類型選型無銀彈，**VARCHAR2 是 99% 場景的正解**；CHAR 只屬於極少數「定長、高頻 JOIN、不介意空間換時間」的特定場景。理解底層語義，才能做出理性決策。