這是一個(gè)在 MySQL 面試和日常開發(fā)中非常經(jīng)典的問題。CHAR 和 VARCHAR 是兩種最常用的字符串?dāng)?shù)據(jù)類型，它們的核心區(qū)別在于存儲(chǔ)和檢索的方式。

下面我將從多個(gè)維度詳細(xì)解釋它們的區(qū)別，并給出選擇建議。

核心區(qū)別總結(jié)

詳細(xì)解釋

1. 存儲(chǔ)方式與空間占用

• CHAR(n)：
  • 你聲明一個(gè) CHAR(10) 的列，無論你存入 "hi"（2字符）還是 "hello"（5字符），MySQL 都會(huì)在磁盤上分配并占用 10 個(gè)字符的空間。
  • 如果存入的字符串長度不足，MySQL 會(huì)在其右側(cè)用空格填充到指定長度。
  • 例如，存儲(chǔ) "A" 到 CHAR(4) 列，實(shí)際存儲(chǔ)的是 "A   "。
• VARCHAR(n)：
  • 你聲明一個(gè) VARCHAR(10) 的列，存入 "hi" 大約占用 3 個(gè)字節(jié)（2個(gè)字符 + 1字節(jié)的長度前綴），存入 "hello" 大約占用 6 個(gè)字節(jié)（5個(gè)字符 + 1字節(jié)的長度前綴）。
  • VARCHAR 需要使用額外的 1 或 2 個(gè)字節(jié)來存儲(chǔ)“字符串的長度”這個(gè)信息。
    • 如果聲明的最大長度 n <= 255，則使用 1 個(gè)字節(jié) 作為長度前綴。
    • 如果聲明的最大長度 n > 255，則使用 2 個(gè)字節(jié) 作為長度前綴。
• 它只存儲(chǔ)實(shí)際的字符串內(nèi)容，不會(huì)用空格填充。

2. 尾部空格的處理（關(guān)鍵行為差異）

這是另一個(gè)非常重要的區(qū)別，尤其是在進(jìn)行字符串比較時(shí)。

CHAR：在檢索（SELECT）時(shí)會(huì)自動(dòng)移除存儲(chǔ)時(shí)填充的尾部空格。

-- 假設(shè)有一個(gè) CHAR(5) 的列
INSERT INTO table (char_column) VALUES ('abc '); -- 存儲(chǔ)為 'abc  '
SELECT char_column, LENGTH(char_column) FROM table; 
-- 檢索結(jié)果：'abc'，長度為 3（尾部空格被移除）

VARCHAR：在檢索時(shí)會(huì)保留尾部空格。

-- 假設(shè)有一個(gè) VARCHAR(5) 的列
INSERT INTO table (varchar_column) VALUES ('abc  '); -- 存儲(chǔ) 'abc  ' 及其長度信息
SELECT varchar_column, LENGTH(varchar_column) FROM table;
-- 檢索結(jié)果：'abc  '，長度為 5（尾部空格被保留）

注意：由于 CHAR 的這種行為，當(dāng)使用 = 比較時(shí)：

'abc '（CHAR）和 'abc'（CHAR）是相等的；

'abc '（CHAR）和 'abc'（VARCHAR）是相等的；

'abc '（VARCHAR）和 'abc'（VARCHAR）是不相等的。

3. 性能考量

• CHAR：
  • 優(yōu)點(diǎn)：由于長度固定，在磁盤上的記錄也是定長的，所以讀寫速度通常更快。MySQL 可以很容易地計(jì)算出第 N 條記錄的位置，尤其是在 MyISAM 這種存儲(chǔ)引擎中，對(duì)于全表掃描或頻繁更新的場(chǎng)景有優(yōu)勢(shì)。
  • 缺點(diǎn)：可能會(huì)浪費(fèi)存儲(chǔ)空間，尤其是當(dāng)存儲(chǔ)的數(shù)據(jù)長度遠(yuǎn)小于定義長度時(shí)。
• VARCHAR：
  • 優(yōu)點(diǎn)：節(jié)省存儲(chǔ)空間。
  • 缺點(diǎn)：由于記錄長度可變，更新數(shù)據(jù)可能會(huì)導(dǎo)致行的大小發(fā)生變化，從而可能引發(fā)頁分裂（對(duì)于 InnoDB），影響一點(diǎn)性能。此外，讀取時(shí)需要先讀取長度信息，再讀取具體數(shù)據(jù)，過程稍復(fù)雜。

如何選擇？

請(qǐng)根據(jù)你的業(yè)務(wù)場(chǎng)景來決定：

• 使用 CHAR 的情況：
  • 存儲(chǔ)的字符串長度非常固定或變化極小。
• 經(jīng)典例子：
  • MD5/SHA1 哈希值（長度固定，如 MD5 總是 32字符）
  • UUID（雖然可以用 CHAR(36)，但現(xiàn)在更推薦存儲(chǔ)為二進(jìn)制或使用 UUID_SHORT()）
  • 國家代碼（如 CHAR(2) 用于 'US', 'CN'）
  • 定長的狀態(tài)碼或標(biāo)志位（如 CHAR(1) 用于 'Y'/‘N’）
• 避免使用CHAR的情況：
  • 需要精確保留字符串的原始格式（包括尾部空格）
• 使用 VARCHAR 的情況：
  • 存儲(chǔ)的字符串長度變化很大。

一個(gè)簡(jiǎn)單的例子

CREATE TABLE test_string (
    id INT PRIMARY KEY,
    fixed_char CHAR(5),
    variable_varchar VARCHAR(5)
);
INSERT INTO test_string (id, fixed_char, variable_varchar) VALUES
(1, 'A', 'A'),       -- CHAR存儲(chǔ) 'A    ', VARCHAR存儲(chǔ) 'A'
(2, 'ABCDE', 'ABCDE'); -- 兩者都存滿
-- 查詢并顯示長度
SELECT 
    fixed_char, 
    LENGTH(fixed_char) as char_length,
    variable_varchar, 
    LENGTH(variable_varchar) as varchar_length
FROM test_string;

結(jié)果可能如下：

總結(jié)

• 追求空間效率，數(shù)據(jù)長度多變 -> 選擇 VARCHAR。這是絕大多數(shù)場(chǎng)景下的選擇。
• 追求極致性能，數(shù)據(jù)長度固定 -> 選擇 CHAR。
• 深刻理解 CHAR 會(huì)剔除檢索結(jié)果的尾部空格 這一點(diǎn)，可以避免很多意想不到的查詢 Bug。

在現(xiàn)代 MySQL 版本和 InnoDB 存儲(chǔ)引擎下，對(duì)于大多數(shù)通用場(chǎng)景，VARCHAR 因其靈活性而更受歡迎。除非你非常確定某個(gè)字段的長度是絕對(duì)固定的，否則從 VARCHAR 開始通常是一個(gè)安全的選擇。

到此這篇關(guān)于mysql中 char 和 varchar 的區(qū)別的文章就介紹到這了,更多相關(guān)mysql char 和 varchar區(qū)別內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論