VARCHAR 和 CHAR 類型

VARCHAR 和 CHAR 是兩種主要的字符串類型，用于存儲(chǔ)字符。不幸的是，由于實(shí)現(xiàn)的方式依賴于存儲(chǔ)引擎，因此很難解釋這些字符串在磁盤和內(nèi)存中如何存儲(chǔ)，除了除了常用的 InnoDB 和 MyISAM 外，假設(shè)你使用了其他存儲(chǔ)引擎，應(yīng)當(dāng)仔細(xì)閱讀存儲(chǔ)引擎的文檔。​

VARCHAR 存儲(chǔ)可變長(zhǎng)度的字符串，也是最常用的字符數(shù)據(jù)類型。相比固定長(zhǎng)度的類型，VARCHAR 所需的存儲(chǔ)空間更小，它會(huì)盡可能少地使用存儲(chǔ)空間（例如，短的字符串占據(jù)的空間）。對(duì)于 MyISAM 來說，如果創(chuàng)建表的時(shí)候指定了 ROW_FORMAT=FIXED 的話，那么會(huì)使用固定的空間存儲(chǔ)字段而導(dǎo)致空間浪費(fèi)。VARCHAR 使用1-2個(gè)額外的字節(jié)存儲(chǔ)字符串的長(zhǎng)度：當(dāng)最大長(zhǎng)度低于255字節(jié)的時(shí)候使用1個(gè)字節(jié)，如果更多的話就使用2個(gè)字節(jié)。因此，拉丁字符集的 VARCHAR(10)會(huì)使用11個(gè)字節(jié)的存儲(chǔ)空間，而 VARCHAR(1000)則會(huì)使用1002個(gè)字節(jié)的存儲(chǔ)空間。​

VARCHAR 由于能夠節(jié)省空間，因此可以改善性能。但是，由于長(zhǎng)度可變，當(dāng)更新數(shù)據(jù)表的時(shí)候數(shù)據(jù)行的存儲(chǔ)空間會(huì)變化，這一定程度上會(huì)帶來額外的開銷。如果數(shù)據(jù)行的長(zhǎng)度導(dǎo)致原有的存儲(chǔ)位置無法存放，那么不同的存儲(chǔ)引擎會(huì)做不同的處理。例如 MyISAM 可能產(chǎn)生數(shù)據(jù)行的碎片，而 InnoDB 需要進(jìn)行磁盤分頁(yè)來存放更新后的數(shù)據(jù)行。​

通常，如果最大的列長(zhǎng)度遠(yuǎn)遠(yuǎn)高于平均長(zhǎng)度的話（例如可選的備注字段），使用 VARCHAR 是劃算的，同時(shí)如果更新的頻次很低，那么碎片化也不會(huì)是一個(gè)問題。需要注意的是，如果使用的是 UTF-8字符集，則實(shí)際存儲(chǔ)的字節(jié)長(zhǎng)度是根據(jù)字符定的。對(duì)于中文，推薦的存儲(chǔ)字符集是 utf8mb4。​

CHAR 類型的長(zhǎng)度是固定的，MySQL 會(huì)對(duì)每個(gè)字段分配足夠的存儲(chǔ)空間。存儲(chǔ)CHAR 類型值的時(shí)候，MySQL 會(huì)移除后面多出來的空字符。值是使用空字符進(jìn)行對(duì)齊以便進(jìn)行比較。對(duì)于短的字符串來說，使用 CHAR 更有優(yōu)勢(shì)，而如果所有的值的長(zhǎng)度幾乎一致的話，就可以使用 CHAR。例如存儲(chǔ)用戶密碼的MD5值時(shí)使用 CHAR 就更合適，這是因?yàn)?MD5的長(zhǎng)度總是固定的。同時(shí)，對(duì)于字段值經(jīng)常改變的數(shù)據(jù)類型來說，CHAR 相比 VARCHAR 也更有優(yōu)勢(shì)，因?yàn)?CHAR 不會(huì)產(chǎn)生碎片。對(duì)于很短的數(shù)據(jù)列，使用 CHAR 比 VARCHAR更高效，例如使用CHAR(1)存儲(chǔ)邏輯值的 Y 和 N，這種情況下只需要1個(gè)字節(jié)，而 VARCHAR 需要2個(gè)字節(jié)。 對(duì)于移除空字符這個(gè)特性會(huì)感覺奇怪，我們舉個(gè)例子：

CREATE TABLE t_char_varchar_test (
  id INT PRIMARY KEY,
  char_col CHAR(10),
  varchar_col VARCHAR(10)
);

INSERT INTO t_char_varchar_test 
VALUES 
(1, 'string1', 'string1'),
(2, '  string2', '  string2'),
(3, 'string3  ', 'string3  ');

按上面的結(jié)果插入數(shù)據(jù)表后，string2中的前置空格不會(huì)移除，但使用 CHAR 類型存儲(chǔ)時(shí)，string3尾隨空格會(huì)被移除，使用 SQL 查詢結(jié)果來檢驗(yàn)一下：

SELECT CONCAT("'", char_col, "'"), CONCAT("'", varchar_col, "'") 
FROM t_char_varchar_test WHERE 1

得出來的結(jié)果如下，可以看到 CHAR 類型的 string3后面的空格被移除了，而 VARCHAR類型的沒有。這種情況大多數(shù)時(shí)候不會(huì)有什么問題，實(shí)際在應(yīng)用中也經(jīng)常會(huì)使用 trim 函數(shù)移除兩端的空字符，但是如果確實(shí)需要存儲(chǔ)空格的時(shí)候，那就需要注意不要選擇使用 CHAR 類型：

數(shù)據(jù)如何存儲(chǔ)是由存儲(chǔ)引擎決定的，而且存儲(chǔ)引擎處理固定長(zhǎng)度和可變長(zhǎng)度的數(shù)據(jù)的方式并不相同。Memory 引擎使用固定大小的行，因此它需要分配最大可能的存儲(chǔ)空間——即便數(shù)據(jù)長(zhǎng)度是可變的。但是，對(duì)于字符串的對(duì)齊和空字符截?cái)嗍怯?MySQL 服務(wù)端完成的，因此所有存儲(chǔ)引擎都是一樣的。​

與 CHAR 和 VARCHAR 相似的是 BINARY和 VARBINARY，用于存儲(chǔ)二進(jìn)制字節(jié)字符，BINARY 的對(duì)齊使用字符0的字節(jié)值來對(duì)齊，并且再獲取值的時(shí)候不會(huì)截?cái)唷Ｈ绻枰褂米址淖止?jié)值而不是字符的話，使用 BINARY 會(huì)更高效，這是因?yàn)楸容^時(shí)，一方面不需要考慮大小寫，另一方面是MySQL一次只比較一個(gè)字節(jié)。​

結(jié)語：

在實(shí)際數(shù)據(jù)表設(shè)計(jì)中，大多數(shù)情況下會(huì)選擇使用 VARCHAR，但 VARCHAR 需要額外的1-2個(gè)字節(jié)存儲(chǔ)字符串長(zhǎng)度。需要注意的是在應(yīng)用中最好能夠限定字段的最大長(zhǎng)度，從而可以使得數(shù)據(jù)表盡可能使用短的 VARCHAR來提高效率。同時(shí)，對(duì)于固定長(zhǎng)度、長(zhǎng)度很短或長(zhǎng)度變化很小的字符類型，推薦使用 CHAR 類存儲(chǔ)，以提高存儲(chǔ)效率。

以上就是MySQL CHAR和VARCHAR的選擇的詳細(xì)內(nèi)容，更多關(guān)于MySQL CHAR和VARCHAR的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！