細(xì)說(shuō)varchar與char有哪些區(qū)別？

小伙伴想精準(zhǔn)查找自己想看的MySQL文章？喏 → MySQL江湖路 | 專欄目錄

CHAR和VARCHAR是MySQL中兩種最重要的字符串類型，兩者的原理和區(qū)別也是面試中高頻問(wèn)題，如果是你，會(huì)從哪幾個(gè)角度去回答這個(gè)問(wèn)題呢？今天，我給大家總結(jié)了一下相關(guān)知識(shí)點(diǎn)，讓我們一起回顧一下吧。 ----- 本文描述和假設(shè)使用的存儲(chǔ)引擎以Innodb和MyISAM為準(zhǔn)

目錄

一、CHAR和VARCHAR有哪些區(qū)別

1、固定長(zhǎng)度 & 可變長(zhǎng)度

2、存儲(chǔ)方式

3、存儲(chǔ)容量

思考：既然VARCHAR長(zhǎng)度可變，那我要不要定到最大?

二、CHAR和VARCHAR在SQL中需要注意的點(diǎn)

三、類似的二進(jìn)制類型：VARBINARY

附、一張有故事的照片（八）

一、CHAR和VARCHAR有哪些區(qū)別

1、固定長(zhǎng)度 & 可變長(zhǎng)度

VARCHAR

VARCHAR類型用于存儲(chǔ)可變長(zhǎng)度字符串，是最常見(jiàn)的字符串?dāng)?shù)據(jù)類型。它比固定長(zhǎng)度類型更節(jié)省空間，因?yàn)樗鼉H使用必要的空間(根據(jù)實(shí)際字符串的長(zhǎng)度改變存儲(chǔ)空間)。

有一種情況例外，如果MySQL表使用ROW_FORMAT=FIXED創(chuàng)建的話，每一行都會(huì)使用定長(zhǎng)存儲(chǔ)。

CHAR

CHAR類型用于存儲(chǔ)固定長(zhǎng)度字符串：MySQL總是根據(jù)定義的字符串長(zhǎng)度分配足夠的空間。當(dāng)存儲(chǔ)CHAR值時(shí)，MySQL會(huì)刪除字符串中的末尾空格(在MySQL 4.1和更老版本中VARCHAR 也是這樣實(shí)現(xiàn)的——也就是說(shuō)這些版本中CHAR和VARCHAR在邏輯上是一樣的，區(qū)別只是在存儲(chǔ)格式上)。

同時(shí)，CHAR值會(huì)根據(jù)需要采用空格進(jìn)行剩余空間填充，以方便比較和檢索。但正因?yàn)槠溟L(zhǎng)度固定，所以會(huì)占據(jù)多余的空間，也是一種空間換時(shí)間的策略；

2、存儲(chǔ)方式

VARCHAR

VARCHAR需要使用1或2個(gè)額外字節(jié)記錄字符串的長(zhǎng)度：如果列的最大長(zhǎng)度小于或等于255字節(jié)，則只使用1個(gè)字節(jié)表示，否則使用2個(gè)字節(jié)。假設(shè)采用latinl字符集，一個(gè)VARCHAR(10)的列需要11個(gè)字節(jié)的存儲(chǔ)空間。VARCHAR(1000)的列則需要1002 個(gè)字節(jié)，因?yàn)樾枰?個(gè)字節(jié)存儲(chǔ)長(zhǎng)度信息。

VARCHAR節(jié)省了存儲(chǔ)空間，所以對(duì)性能也有幫助。但是，由于行是變長(zhǎng)的，在UPDATE時(shí)可能使行變得比原來(lái)更長(zhǎng)，這就導(dǎo)致需要做額外的工作。如果一個(gè)行占用的空間增長(zhǎng)，并且在頁(yè)內(nèi)沒(méi)有更多的空間可以存儲(chǔ)，在這種情況下，不同的存儲(chǔ)引擎的處理方式是不一樣的。例如，MylSAM會(huì)將行拆成不同的片段存儲(chǔ)，InnoDB則需要分裂頁(yè)來(lái)使行可以放進(jìn)頁(yè)內(nèi)。

CHAR

CHAR適合存儲(chǔ)很短或長(zhǎng)度近似的字符串。例如，CHAR非常適合存儲(chǔ)密碼的MD5值，因?yàn)檫@是一個(gè)定長(zhǎng)的值。對(duì)于經(jīng)常變更的數(shù)據(jù)，CHAR也比VARCHAR更好，因?yàn)槎ㄩL(zhǎng)的CHAR類型不容易產(chǎn)生碎片。對(duì)于非常短的列，CHAR比VARCHAR在存儲(chǔ)空間上也更有效率。例如用CHAR(1)來(lái)存儲(chǔ)只有Y和N的值，如果采用單字節(jié)字符集只需要一個(gè)字節(jié)，但是VARCHAR(1)卻需要兩個(gè)字節(jié)，因?yàn)檫€有一個(gè)記錄長(zhǎng)度的額外字節(jié)。

3、存儲(chǔ)容量

CHAR

對(duì)于char類型來(lái)說(shuō)，最多只能存放的字符個(gè)數(shù)為255，和編碼無(wú)關(guān)，任何編碼最大容量都是255。

VARCHAR

MySQL行默認(rèn)最大65535字節(jié)，是所有列共享（相加）的，所以VARCHAR的最大值受此限制。

表中只有單列字段情況下，varchar一般最多能存放(65535 - 3)個(gè)字節(jié)，varchar的最大有效長(zhǎng)度通過(guò)最大行數(shù)據(jù)長(zhǎng)度和使用的字符集來(lái)確定，通常的最大長(zhǎng)度是65532個(gè)字符（當(dāng)字符串中的字符都只占1個(gè)字節(jié)時(shí)，能達(dá)到65532個(gè)字符）；

為什么是65532個(gè)字符？算法如下（有余數(shù)時(shí)向下取整）：

最大長(zhǎng)度(字符數(shù)) = （行存儲(chǔ)最大字節(jié)數(shù) - NULL標(biāo)識(shí)列占用字節(jié)數(shù) - 長(zhǎng)度標(biāo)識(shí)字節(jié)數(shù)） / 字符集單字符最大字節(jié)數(shù)

NULL標(biāo)識(shí)列占用字節(jié)數(shù)：允許NULL時(shí)，占一字節(jié)

長(zhǎng)度標(biāo)識(shí)字節(jié)數(shù)：記錄長(zhǎng)度的標(biāo)識(shí)，長(zhǎng)度小于等于255（28）時(shí)，占1字節(jié)；小于65535時(shí)（216）,占2字節(jié)

VARCHAR類型在4.1和5.0版本發(fā)生了很大的變化，使得情況更加復(fù)雜。從MySQL 4.1開(kāi)始，每個(gè)字符串列可以定義自己的字符集和排序規(guī)則。這些東西會(huì)很大程度上影響性能。

4.0版本及以下，MySQL中varchar長(zhǎng)度是按字節(jié)展示，如varchar(20)，指的是20字節(jié)；

5.0版本及以上，MySQL中varchar長(zhǎng)度是按字符展示。如varchar(20)，指的是20字符。

當(dāng)然，行總長(zhǎng)度還是65535字節(jié)，而字符和字節(jié)的換算，則與編碼方式有關(guān)，不同的字符所占的字節(jié)是不同的。編碼劃分如下：

GBK編碼：

一個(gè)英文字符占一個(gè)字節(jié)，中文2字節(jié)，單字符最大可占用2個(gè)字節(jié)。

UTF-8編碼：

一個(gè)英文字符占一個(gè)字節(jié)，中文3字節(jié)，單字符最大可占用3個(gè)字節(jié)。

utf8mb4編碼：

一個(gè)英文字符占一個(gè)字節(jié)，中文3字節(jié)，單字符最大占4個(gè)字節(jié)（如emoji表情4字節(jié)）。

假設(shè)當(dāng)前還有6字節(jié)可以存放字符，按單字符占用最大字節(jié)數(shù)來(lái)算，可以存放3個(gè)GBK、或2個(gè)utf8、或1個(gè)utf8mb4。

思考：既然VARCHAR長(zhǎng)度可變，那我要不要定到最大?

沒(méi)錯(cuò)，相信你已經(jīng)有答案了，別這么干！

就像使用VARCHAR(5)和VARCHAR(200)存儲(chǔ) '陳哈哈’的磁盤(pán)空間開(kāi)銷(xiāo)是一樣的。那么使用更短的列有什么優(yōu)勢(shì)呢？

事實(shí)證明有很大的優(yōu)勢(shì)。更長(zhǎng)的列會(huì)消耗更多的內(nèi)存，因?yàn)镸ySQL通常會(huì)分配固定大小的內(nèi)存塊來(lái)保存內(nèi)部值。

當(dāng)然，在沒(méi)拿到存儲(chǔ)引擎存儲(chǔ)的數(shù)據(jù)之前，并不會(huì)知道我這一行拿出來(lái)的數(shù)據(jù)到底有多長(zhǎng)，可能長(zhǎng)度只有1，可能長(zhǎng)度是500，那怎么辦呢？那就只能先把最大空間分配好了，避免放不下的問(wèn)題發(fā)生，這樣實(shí)際上對(duì)于真實(shí)數(shù)據(jù)較短的varchar確實(shí)會(huì)造成空間的浪費(fèi)。

舉例：我向數(shù)據(jù)類型為：varchar（1000）的列插入了1024行數(shù)據(jù)，但是每個(gè)只存一個(gè)字符，那么這1024行真實(shí)數(shù)據(jù)量其實(shí)只有1K，但是我卻需要約1M的內(nèi)存去適應(yīng)他。所以最好的策略是只分配真正需要的空間。

二、CHAR和VARCHAR在SQL中需要注意的點(diǎn)

下面通過(guò)一個(gè)具體的示例來(lái)說(shuō)明CHAR和VARCHAR類型存儲(chǔ)時(shí)的區(qū)別。我們創(chuàng)建一張同時(shí)存在CHAR(10)字段、VARCHAR(10)字段的表，并且往里面插入一些值來(lái)做對(duì)比驗(yàn)證：

-- 建表語(yǔ)句 CREATE TABLE `str_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `str_char` char(10) DEFAULT NULL, `str_varchar` varchar(10) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8mb4;

1

2

3

4

5

6

7

分別插入一些字符串前面和后面都有空格的示例

-- 插入測(cè)試數(shù)據(jù) INSERT INTO `str_table` (`id`, `str_char`, `str_varchar`) VALUES (null, '陳哈哈', '陳哈哈'), (null, ' 陳哈哈', ' 陳哈哈'), (null, '陳哈哈 ', '陳哈哈 ');

1

2

3

4

5

6

測(cè)試數(shù)據(jù)查詢語(yǔ)句如下，通過(guò)拼接能更好的看出對(duì)比效果：

-- 測(cè)試數(shù)據(jù)查詢 select id,concat("|",str_char,"|") as `char`,concat("|",str_varchar,"|") as `varchar` from str_table;

1

2

mysql> select id,concat("|",str_char,"|") as `char`,concat("|",str_varchar,"|") as `varchar` from str_table; +----+---------------+---------------+ | id | char | varchar | +----+---------------+---------------+ | 6 | |陳哈哈| | |陳哈哈| | | 7 | | 陳哈哈| | | 陳哈哈| | | 8 | |陳哈哈| | |陳哈哈 | | +----+---------------+---------------+ 3 rows in set (0.00 sec)

1

2

3

4

5

6

7

8

9

當(dāng)檢索這些值的時(shí)候，會(huì)發(fā)現(xiàn)id=8行中，char類型的"陳哈哈 "末尾的空格被截?cái)嗔耍鳹ARCHAR(10)字段存儲(chǔ)相同的值時(shí)，末尾的空格被保留了。

另外，id=7行的數(shù)據(jù)前面空格都被保留了。

可見(jiàn)，CHAR會(huì)默認(rèn)切掉字符串末尾的空格，如果需要保留末尾的空格，記得用varchar類型！

三、類似的二進(jìn)制類型：VARBINARY

與CHAR和VARCHAR類似的類型還有BINARY和VARBINARY,它們存儲(chǔ)的是二進(jìn)制字符串。二進(jìn)制字符串跟常規(guī)字符串非常相似，但是二進(jìn)制字符串存儲(chǔ)的是字節(jié)碼而不是字符。 填充也不一樣：MySQL填充BINARY采用的是\0 (零字節(jié))而不是空格，在檢索時(shí)也不會(huì)去掉填充值。

當(dāng)需要存儲(chǔ)二進(jìn)制數(shù)據(jù)，并且希望MySQL使用字節(jié)碼而不是字符進(jìn)行比較時(shí)，這些類型是非常有用的。二進(jìn)制比較的優(yōu)勢(shì)并不僅僅體現(xiàn)在大小寫(xiě)敏感上。MySQL比較BINARY字符串時(shí)，每次按一個(gè)字節(jié)，并且根據(jù)該字節(jié)的數(shù)值進(jìn)行比較。因此，二進(jìn)制比 較比字符比較簡(jiǎn)單很多，所以也就更快。

varchar

varchar是可變長(zhǎng)度字符類型，如果對(duì)應(yīng)的數(shù)據(jù)庫(kù)排序規(guī)則是utf8_general_ci，那么查詢的時(shí)候?qū)⒉粎^(qū)分大小寫(xiě)。如果排序規(guī)則是utf8_bin，則會(huì)區(qū)分大小寫(xiě)。

varbinary

varbinary是二進(jìn)制字符類型，在排序規(guī)則utf8_general_ci下，是可以區(qū)分大小寫(xiě)的。

附、一張有故事的照片（八）

一場(chǎng)山火過(guò)后

一只雌山雞體無(wú)完膚的躺在自己的窩巢旁

巢里是已經(jīng)燒熟了的蛋

直到最后一刻

她也沒(méi)有離開(kāi)自己的孩子

MySQL

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。