詳解數(shù)據(jù)庫varchar與char有哪些區(qū)別
CHAR和VARCHAR是MySQL中兩種最重要的字符串類型,兩者的原理和區(qū)別也是面試中高頻問題,如果是你,會(huì)從哪幾個(gè)角度去回答這個(gè)問題呢?今天,我給大家總結(jié)了一下相關(guān)知識(shí)點(diǎn),讓我們一起回顧一下吧。 ----- 本文描述和假設(shè)使用的存儲(chǔ)引擎以Innodb和MyISAM為準(zhǔn)
一、CHAR和VARCHAR有哪些區(qū)別
1、固定長度 & 可變長度
- VARCHAR
VARCHAR類型用于存儲(chǔ)可變長度
字符串,是最常見的字符串?dāng)?shù)據(jù)類型。它比固定長度類型更節(jié)省空間,因?yàn)樗鼉H使用必要的空間(根據(jù)實(shí)際字符串的長度改變存儲(chǔ)空間)。
有一種情況例外,如果MySQL表使用ROW_FORMAT=FIXED創(chuàng)建的話,每一行都會(huì)使用定長存儲(chǔ)。
- CHAR
CHAR類型用于存儲(chǔ)固定長度
字符串:MySQL總是根據(jù)定義的字符串長度分配足夠的空間。當(dāng)存儲(chǔ)CHAR值時(shí),MySQL會(huì)刪除字符串中的末尾空格
(在MySQL 4.1和更老版本中VARCHAR 也是這樣實(shí)現(xiàn)的——也就是說這些版本中CHAR和VARCHAR在邏輯上是一樣的,區(qū)別只是在存儲(chǔ)格式上)。
同時(shí),CHAR值會(huì)根據(jù)需要采用空格進(jìn)行剩余空間填充
,以方便比較和檢索。但正因?yàn)槠溟L度固定,所以會(huì)占據(jù)多余的空間,也是一種空間換時(shí)間的策略;
2、存儲(chǔ)方式
- VARCHAR
VARCHAR需要使用1或2個(gè)額外字節(jié)記錄字符串的長度:如果列的最大長度小于或等于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ǔ)長度信息。
VARCHAR節(jié)省了存儲(chǔ)空間,所以對性能也有幫助。但是,由于行是變長的,在UPDATE時(shí)可能使行變得比原來更長,這就導(dǎo)致需要做額外的工作。如果一個(gè)行占用的空間增長,并且在頁內(nèi)沒有更多的空間可以存儲(chǔ),在這種情況下,不同的存儲(chǔ)引擎的處理方式是不一樣的。例如,MylSAM會(huì)將行拆成不同的片段存儲(chǔ),InnoDB則需要分裂頁來使行可以放進(jìn)頁內(nèi)。
- CHAR
CHAR適合存儲(chǔ)很短或長度近似的字符串。例如,CHAR非常適合存儲(chǔ)密碼的MD5值,因?yàn)檫@是一個(gè)定長的值。對于經(jīng)常變更的數(shù)據(jù),CHAR也比VARCHAR更好,因?yàn)槎ㄩL的CHAR類型不容易產(chǎn)生碎片。對于非常短的列,CHAR比VARCHAR在存儲(chǔ)空間上也更有效率。例如用CHAR(1)來存儲(chǔ)只有Y和N的值,如果采用單字節(jié)字符集只需要一個(gè)字節(jié),但是VARCHAR(1)卻需要兩個(gè)字節(jié),因?yàn)檫€有一個(gè)記錄長度的額外字節(jié)。
3、存儲(chǔ)容量 CHAR
對于char類型來說,最多只能存放的字符個(gè)數(shù)為255,和編碼無關(guān),任何編碼最大容量都是255。
- VARCHAR
MySQL行
默認(rèn)最大65535字節(jié),是所有列共享(相加)的,所以VARCHAR的最大值受此限制。
表中只有單列字段
情況下,varchar一般最多能存放(65535 - 3)個(gè)字節(jié)
,varchar的最大有效長度通過最大行數(shù)據(jù)長度
和使用的字符集
來確定,通常的最大長度是65532個(gè)字符(當(dāng)字符串中的字符都只占1個(gè)字節(jié)時(shí),能達(dá)到65532個(gè)字符)
;
為什么是65532個(gè)字符?算法如下(有余數(shù)時(shí)向下取整):
最大長度(字符數(shù)) = (行存儲(chǔ)最大字節(jié)數(shù) - NULL標(biāo)識(shí)列占用字節(jié)數(shù) - 長度標(biāo)識(shí)字節(jié)數(shù)) / 字符集單字符最大字節(jié)數(shù)
NULL標(biāo)識(shí)列占用字節(jié)數(shù)
:允許NULL時(shí),占一字節(jié)長度標(biāo)識(shí)字節(jié)數(shù)
:記錄長度的標(biāo)識(shí),長度小于等于255(28)時(shí),占1字節(jié);小于65535時(shí)(216),占2字節(jié)
VARCHAR類型在4.1和5.0版本發(fā)生了很大的變化,使得情況更加復(fù)雜。從MySQL 4.1開始,每個(gè)字符串列可以定義自己的字符集和排序規(guī)則。這些東西會(huì)很大程度上影響性能。
- 4.0版本及以下,MySQL中varchar長度是按
字節(jié)
展示,如varchar(20),指的是20字節(jié)
; - 5.0版本及以上,MySQL中varchar長度是按
字符
展示。如varchar(20),指的是20字符
。
當(dā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ù)來算,可以存放3個(gè)GBK、或2個(gè)utf8、或1個(gè)utf8mb4。
思考:既然VARCHAR長度可變,那我要不要定到最大?
沒錯(cuò),相信你已經(jīng)有答案了,別這么干!
就像使用VARCHAR(5)和VARCHAR(200)存儲(chǔ) '陳哈哈’的磁盤空間開銷是一樣的。那么使用更短的列有什么優(yōu)勢呢?
事實(shí)證明有很大的優(yōu)勢。更長的列會(huì)消耗更多的內(nèi)存,因?yàn)镸ySQL通常會(huì)分配固定大小的內(nèi)存塊來保存內(nèi)部值。
當(dāng)然,在沒拿到存儲(chǔ)引擎存儲(chǔ)的數(shù)據(jù)之前,并不會(huì)知道我這一行拿出來的數(shù)據(jù)到底有多長,可能長度只有1,可能長度是500,那怎么辦呢?那就只能先把最大空間分配好了,避免放不下的問題發(fā)生,這樣實(shí)際上對于真實(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)
下面通過一個(gè)具體的示例來說明CHAR和VARCHAR類型存儲(chǔ)時(shí)的區(qū)別。我們創(chuàng)建一張同時(shí)存在CHAR(10)字段、VARCHAR(10)字段的表,并且往里面插入一些值來做對比驗(yàn)證:
-- 建表語句 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;
分別插入一些字符串前面和后面都有空格的示例
-- 插入測試數(shù)據(jù) INSERT INTO `str_table` (`id`, `str_char`, `str_varchar`) VALUES (null, '陳哈哈', '陳哈哈'), (null, ' 陳哈哈', ' 陳哈哈'), (null, '陳哈哈 ', '陳哈哈 ');
測試數(shù)據(jù)查詢語句如下,通過拼接能更好的看出對比效果:
-- 測試數(shù)據(jù)查詢 select id,concat("|",str_char,"|") as `char`,concat("|",str_varchar,"|") as `varchar` from str_table;
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)
- 當(dāng)檢索這些值的時(shí)候,會(huì)發(fā)現(xiàn)id=8行中,char類型的"陳哈哈 "末尾的空格被截?cái)嗔?,而VARCHAR(10)字段存儲(chǔ)相同的值時(shí),末尾的空格被保留了。
- 另外,id=7行的數(shù)據(jù)前面空格都被保留了。
可見,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)勢并不僅僅體現(xiàn)在大小寫敏感上。MySQL比較BINARY字符串時(shí),每次按一個(gè)字節(jié),并且根據(jù)該字節(jié)的數(shù)值進(jìn)行比較。因此,二進(jìn)制比 較比字符比較簡單很多,所以也就更快。
- varchar
varchar是可變長度字符類型
,如果對應(yīng)的數(shù)據(jù)庫排序規(guī)則是utf8_general_ci,那么查詢的時(shí)候?qū)⒉粎^(qū)分大小寫。如果排序規(guī)則是utf8_bin,則會(huì)區(qū)分大小寫。
- varbinary
varbinary是二進(jìn)制字符類型
,在排序規(guī)則utf8_general_ci下,是可以區(qū)分大小寫的。
到此這篇關(guān)于詳解數(shù)據(jù)庫varchar與char有哪些區(qū)別的文章就介紹到這了,更多相關(guān)varchar與char區(qū)別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
- sql中的char與varchar有什么區(qū)別
- MySQL中varchar和char類型的區(qū)別
- MYSQL中 char 和 varchar的區(qū)別
- Oralce中VARCHAR2()與NVARCHAR2()的區(qū)別介紹
- MySQL中VARCHAR與CHAR格式數(shù)據(jù)的區(qū)別
- MySQL數(shù)據(jù)庫char與varchar的區(qū)別分析及使用建議
- 深入SQL Server中定長char(n)與變長varchar(n)的區(qū)別詳解
- 深入SQL Server中char、varchar、text和nchar、nvarchar、ntext的區(qū)別詳解
- Sqlserver中char,nchar,varchar與Nvarchar的區(qū)別分析
相關(guān)文章
分頁技術(shù)原理與實(shí)現(xiàn)之分頁的意義及方法(一)
這篇文章主要介紹了分頁技術(shù)原理與實(shí)現(xiàn)第一篇:為什么要進(jìn)行分頁及怎么分頁,感興趣的小伙伴們可以參考一下2016-06-06mysql實(shí)現(xiàn)查詢每門課程成績最好的前兩名學(xué)生id和姓名
這篇文章主要介紹了mysql實(shí)現(xiàn)查詢每門課程成績最好的前兩名學(xué)生id和姓名方式,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2023-11-11MySQL優(yōu)化之SQL調(diào)優(yōu)策略分享
這篇文章主要介紹了MySQL優(yōu)化之SQL調(diào)優(yōu)策略,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2025-04-04MySQL實(shí)現(xiàn)類似Oracle序列的方案
今天小編就為大家分享一篇關(guān)于MySQL實(shí)現(xiàn)類似Oracle序列的方案,小編覺得內(nèi)容挺不錯(cuò)的,現(xiàn)在分享給大家,具有很好的參考價(jià)值,需要的朋友一起跟隨小編來看看吧2019-03-03