MySQL VARCHAR(20) vs VARCHAR(255) 性能影響深度分析：索引長度、內存分配、ROW_FORMAT 差異

MySQL VARCHAR(20) vs VARCHAR(255) 性能影響深度分析：索引長度、內存分配、ROW_FORMAT 差異

許多開發者習慣「保守起見全用 VARCHAR(255)」，實際上長度定義直接影響索引大小、內存分配、排序緩衝、臨時表等核心性能指標。本文從索引 key_len 計算、ROW_FORMAT=FIXED 行存儲、排序/臨時表內存三個維度量化差異。

一、索引長度與 key_len 計算

建立索引時若不指定前綴長度，索引長度默認等於列定義長度。

-- 測試表
CREATE TABLE abc (id INT, name VARCHAR(20)) ENGINE=InnoDB CHARSET=utf8;
ALTER TABLE abc ADD INDEX idx_name (name);
EXPLAIN SELECT name FROM abc;  -- key_len = 20*3(utf8) + 2(變長) + 1(NULL) = 63

ALTER TABLE abc MODIFY name VARCHAR(255);
EXPLAIN SELECT name FROM abc;  -- key_len = 255*3 + 2 + 1 = 768

key_len 計算公式

結論：VARCHAR(255) 索引條目佔用 12 倍 內存，導致 Buffer Pool 容納的索引頁數銳減，磁碟 IO 增加。

二、ROW_FORMAT=FIXED (MyISAM) 固定行長存儲

CREATE TABLE t_fixed (c VARCHAR(20)) ENGINE=MyISAM ROW_FORMAT=FIXED;
CREATE TABLE t_fixed255 (c VARCHAR(255)) ENGINE=MyISAM ROW_FORMAT=FIXED;
-- 插入相同 'hello'
-- t_fixed  每行固定佔用 20*3 = 60 字節
-- t_fixed255 每行固定佔用 255*3 = 765 字節

雖然 InnoDB 預設 DYNAMIC/COMPRESSED 不受影響，但MyISAM 表若誤用 FIXED，空間浪費極大。

三、排序緩衝與臨時表內存分配

• sort_buffer_size、join_buffer_size、tmp_table_size、max_heap_table_size 等參數按列定義最大長度預分配內存。
• VARCHAR(255) 導致每行在排序/哈希連接/內存臨時表中預留 768 字節（utf8mb4），實際存『hello』僅 5 字節，**利用率 < 1%**。
• 大查詢並發時，內存壓力指數級上升，觸發磁碟臨時表、文件排序，性能崩塌。

四、實測對比數據（模擬 100 萬行，utf8mb4）

五、最佳實踐建議

1. 業務實際最大長度 + 20% 冗余 定義 VARCHAR，如手機號 VARCHAR(11)、郵箱 VARCHAR(64)、URL VARCHAR(255)。
2. 避免「萬能 VARCHAR(255)」，除非業務真需要。
3. 頻繁作為排序、分組、連接鍵的列，越短越好。
4. InnoDB 大字段（>768 字節）自動溢出頁，VARCHAR(255) 尚未觸發，但索引仍完整存儲。
5. Schema 變更縮短長度：ALTER TABLE ... MODIFY col VARCHAR(new_len)（需重建表，規劃窗口期）。

「精確定義長度」是零成本、高收益的性能優化手段，建議納入代碼評審清單，從源頭杜絕過度定長。