mysql中char與varchar的區(qū)別分析
更新時間:2010年05月20日 01:25:29 作者:
在mysql教程中char與varchar的區(qū)別呢,都是用來存儲字符串的,只是他們的保存方式不一樣罷了,char有固定的長度,而varchar屬于可變長的字符類型。
char與varchar的區(qū)別
char (13)長度固定, 如'www.dbjr.com.cn' 存儲需要空間 12個字符
varchar(13) 可變長 如'www.dbjr.com.cn' 需要存儲空間 13字符,
從上面可以看得出來char 長度是固定的,不管你存儲的數(shù)據(jù)是多少他都會都固定的長度。而varchar則處可變長度但他要在總長度上加1字符,這個用來存儲位置。所以實(shí)際應(yīng)用中用戶可以根據(jù)自己的數(shù)據(jù)類型來做。
再看看char,與varchar在速度上的區(qū)別吧。
mysal>create tabe ab(v varchar(4),c char(4));
query ok ,0 rows affected(0.02 sec)
mysql>insert into abc values('ab ','ab ')
query ok ,1 row affected(0.00 sec);
mysql->select concat(v ,'+') ,concat(c ,'+') form abc
ab + | ab+
1rows in set (0.00 sec)
從上面可以看出來,由于某種原因char 固定長度,所以在處理速度上要比varchar快速很多,但是對費(fèi)存儲空間,所以對存儲不大,但在速度上有要求的可以使用char類型,反之可以用varchar類型來實(shí)例。
注明:
在用char字符類型時內(nèi)容后面有空間時必須作相關(guān)處理,要不就會把空格自動刪除。
建意:
myisam 存儲引擎 建議使用固定長度,數(shù)據(jù)列代替可變長度的數(shù)據(jù)列。
memory存儲引擎 目前都使用固定數(shù)據(jù)行存儲,因此無論使用char varchar列都沒關(guān)系,
innodb 存儲引擎 建意使用varchar 類型
以下是其它網(wǎng)友的補(bǔ)充
char是一種固定長度的類型,varchar則是一種可變長度的類型
char(M)類型的數(shù)據(jù)列里,每個值都占用M個字節(jié),如果某個長度小于M,MySQL就會在它的右邊用空格字符補(bǔ)足.(在檢索操作中那些填補(bǔ)出來的空格字符將被去掉)在varchar(M)類型的數(shù)據(jù)列里,每個值只占用剛好夠用的字節(jié)再加上一個用來記錄其長度的字節(jié)(即總長度為L+1字節(jié)).
在MySQL中用來判斷是否需要進(jìn)行對據(jù)列類型轉(zhuǎn)換的規(guī)則
?。薄⒃谝粋€數(shù)據(jù)表里,如果每一個數(shù)據(jù)列的長度都是固定的,那么每一個數(shù)據(jù)行的長度也將是固定的.
?。病⒅灰獢?shù)據(jù)表里有一個數(shù)據(jù)列的長度的可變的,那么各數(shù)據(jù)行的長度都是可變的.
?。?、如果某個數(shù)據(jù)表里的數(shù)據(jù)行的長度是可變的,那么,為了節(jié)約存儲空間,MySQL會把這個數(shù)據(jù)表里的固定長度類型的數(shù)據(jù)列轉(zhuǎn)換為相應(yīng)的可變長度類型.
例外:長度小于4個字符的char數(shù)據(jù)列不會被轉(zhuǎn)換為varchar類型
對于MyISAM表,盡量使用Char,對于那些經(jīng)常需要修改而容易形成碎片的myisam和isam數(shù)據(jù)表就更是如此,它的缺點(diǎn)就是占用磁盤空間;
對于InnoDB表,因?yàn)樗臄?shù)據(jù)行內(nèi)部存儲格式對固定長度的數(shù)據(jù)行和可變長度的數(shù)據(jù)行不加區(qū)分(所有數(shù)據(jù)行共用一個表頭部分,這個標(biāo)頭部分存放著指向各有關(guān)數(shù)據(jù)列的指針),所以使用char類型不見得會比使用varchar類型好。事實(shí)上,因?yàn)閏har類型通常要比varchar類型占用更多的空間,所以從減少空間占用量和減少磁盤i/o的角度,使用varchar類型反而更有利.
文章2:
字符應(yīng)該是最常見的一種了,但似乎各個數(shù)據(jù)庫都有所不同,比如oracle中就有啥varchar2之類。不過mysql似乎最多的還是集中在char和varchar上。
說說區(qū)別。char是固定長度的,而varchar會根據(jù)具體的長度來使用存儲空間。比如char(255)和varchar(255),在存儲字符串"hello world"的時候,char會用一塊255的空間放那個11個字符,而varchar就不會用255個,他先計(jì)算長度后只用11個再加上計(jì)算的到字符串長度信息,一般1-2個byte來,這樣varchar在存儲不確定長度的時候會大大減少存儲空間。
如此看來varchar比char聰明多了,那char有用武之地嗎?還是很不少優(yōu)勢的。
一,存儲很短的信息,比如門牌號碼101,201……這樣很短的信息應(yīng)該用char,因?yàn)関archar還要占個byte用于存儲信息長度,本來打算節(jié)約存儲的現(xiàn)在得不償失。
二,固定長度的。比如使用uuid作為主鍵,那用char應(yīng)該更合適。因?yàn)樗潭ㄩL度,varchar動態(tài)根據(jù)長度的特性就消失了,而且還要占個長度信息。
三,十分頻繁改變的column。因?yàn)関archar每次存儲都要有額外的計(jì)算,得到長度等工作,如果一個非常頻繁改變的,那就要有很多的精力用于計(jì)算,而這些對于char來說是不需要的。
還有一個關(guān)于varchar的問題是,varchar他既然可以自動適應(yīng)存儲空間,那我varchar(8)和varchar(255)存儲應(yīng)該都是一樣的,那每次表設(shè)計(jì)的時候往大的方向去好了,免得以后不夠用麻煩。這個思路對嗎?答案是否定的。mysql會把表信息放到內(nèi)存中(查詢第一次后,就緩存住了,linux下很明顯,但windows下似乎沒有,不知道為啥),這時內(nèi)存的申請是按照固定長度來的,如果varchar很大就會有問題。所以還是應(yīng)該按需索取。
總結(jié):仔細(xì)看DZ的數(shù)據(jù)表,定長的字段基本還都是用char....
char (13)長度固定, 如'www.dbjr.com.cn' 存儲需要空間 12個字符
varchar(13) 可變長 如'www.dbjr.com.cn' 需要存儲空間 13字符,
從上面可以看得出來char 長度是固定的,不管你存儲的數(shù)據(jù)是多少他都會都固定的長度。而varchar則處可變長度但他要在總長度上加1字符,這個用來存儲位置。所以實(shí)際應(yīng)用中用戶可以根據(jù)自己的數(shù)據(jù)類型來做。
再看看char,與varchar在速度上的區(qū)別吧。
復(fù)制代碼 代碼如下:
mysal>create tabe ab(v varchar(4),c char(4));
query ok ,0 rows affected(0.02 sec)
mysql>insert into abc values('ab ','ab ')
query ok ,1 row affected(0.00 sec);
mysql->select concat(v ,'+') ,concat(c ,'+') form abc
ab + | ab+
1rows in set (0.00 sec)
從上面可以看出來,由于某種原因char 固定長度,所以在處理速度上要比varchar快速很多,但是對費(fèi)存儲空間,所以對存儲不大,但在速度上有要求的可以使用char類型,反之可以用varchar類型來實(shí)例。
注明:
在用char字符類型時內(nèi)容后面有空間時必須作相關(guān)處理,要不就會把空格自動刪除。
建意:
myisam 存儲引擎 建議使用固定長度,數(shù)據(jù)列代替可變長度的數(shù)據(jù)列。
memory存儲引擎 目前都使用固定數(shù)據(jù)行存儲,因此無論使用char varchar列都沒關(guān)系,
innodb 存儲引擎 建意使用varchar 類型
以下是其它網(wǎng)友的補(bǔ)充
char是一種固定長度的類型,varchar則是一種可變長度的類型
char(M)類型的數(shù)據(jù)列里,每個值都占用M個字節(jié),如果某個長度小于M,MySQL就會在它的右邊用空格字符補(bǔ)足.(在檢索操作中那些填補(bǔ)出來的空格字符將被去掉)在varchar(M)類型的數(shù)據(jù)列里,每個值只占用剛好夠用的字節(jié)再加上一個用來記錄其長度的字節(jié)(即總長度為L+1字節(jié)).
在MySQL中用來判斷是否需要進(jìn)行對據(jù)列類型轉(zhuǎn)換的規(guī)則
?。薄⒃谝粋€數(shù)據(jù)表里,如果每一個數(shù)據(jù)列的長度都是固定的,那么每一個數(shù)據(jù)行的長度也將是固定的.
?。病⒅灰獢?shù)據(jù)表里有一個數(shù)據(jù)列的長度的可變的,那么各數(shù)據(jù)行的長度都是可變的.
?。?、如果某個數(shù)據(jù)表里的數(shù)據(jù)行的長度是可變的,那么,為了節(jié)約存儲空間,MySQL會把這個數(shù)據(jù)表里的固定長度類型的數(shù)據(jù)列轉(zhuǎn)換為相應(yīng)的可變長度類型.
例外:長度小于4個字符的char數(shù)據(jù)列不會被轉(zhuǎn)換為varchar類型
對于MyISAM表,盡量使用Char,對于那些經(jīng)常需要修改而容易形成碎片的myisam和isam數(shù)據(jù)表就更是如此,它的缺點(diǎn)就是占用磁盤空間;
對于InnoDB表,因?yàn)樗臄?shù)據(jù)行內(nèi)部存儲格式對固定長度的數(shù)據(jù)行和可變長度的數(shù)據(jù)行不加區(qū)分(所有數(shù)據(jù)行共用一個表頭部分,這個標(biāo)頭部分存放著指向各有關(guān)數(shù)據(jù)列的指針),所以使用char類型不見得會比使用varchar類型好。事實(shí)上,因?yàn)閏har類型通常要比varchar類型占用更多的空間,所以從減少空間占用量和減少磁盤i/o的角度,使用varchar類型反而更有利.
文章2:
字符應(yīng)該是最常見的一種了,但似乎各個數(shù)據(jù)庫都有所不同,比如oracle中就有啥varchar2之類。不過mysql似乎最多的還是集中在char和varchar上。
說說區(qū)別。char是固定長度的,而varchar會根據(jù)具體的長度來使用存儲空間。比如char(255)和varchar(255),在存儲字符串"hello world"的時候,char會用一塊255的空間放那個11個字符,而varchar就不會用255個,他先計(jì)算長度后只用11個再加上計(jì)算的到字符串長度信息,一般1-2個byte來,這樣varchar在存儲不確定長度的時候會大大減少存儲空間。
如此看來varchar比char聰明多了,那char有用武之地嗎?還是很不少優(yōu)勢的。
一,存儲很短的信息,比如門牌號碼101,201……這樣很短的信息應(yīng)該用char,因?yàn)関archar還要占個byte用于存儲信息長度,本來打算節(jié)約存儲的現(xiàn)在得不償失。
二,固定長度的。比如使用uuid作為主鍵,那用char應(yīng)該更合適。因?yàn)樗潭ㄩL度,varchar動態(tài)根據(jù)長度的特性就消失了,而且還要占個長度信息。
三,十分頻繁改變的column。因?yàn)関archar每次存儲都要有額外的計(jì)算,得到長度等工作,如果一個非常頻繁改變的,那就要有很多的精力用于計(jì)算,而這些對于char來說是不需要的。
還有一個關(guān)于varchar的問題是,varchar他既然可以自動適應(yīng)存儲空間,那我varchar(8)和varchar(255)存儲應(yīng)該都是一樣的,那每次表設(shè)計(jì)的時候往大的方向去好了,免得以后不夠用麻煩。這個思路對嗎?答案是否定的。mysql會把表信息放到內(nèi)存中(查詢第一次后,就緩存住了,linux下很明顯,但windows下似乎沒有,不知道為啥),這時內(nèi)存的申請是按照固定長度來的,如果varchar很大就會有問題。所以還是應(yīng)該按需索取。
總結(jié):仔細(xì)看DZ的數(shù)據(jù)表,定長的字段基本還都是用char....
相關(guān)文章
從MySQL復(fù)制功能中得到的一舉三得實(shí)惠分析
在MySQL數(shù)據(jù)庫中,支持單項(xiàng)、異步復(fù)制。在復(fù)制過程中,一個服務(wù)器充當(dāng)主服務(wù)器,而另外一臺服務(wù)器充當(dāng)從服務(wù)器。筆者通過MySQL的復(fù)制功能得到了一下實(shí)惠,在下文中與大家分享。2011-03-03MySQL數(shù)據(jù)庫索引原理及優(yōu)化策略
MySQL數(shù)據(jù)庫索引是一種數(shù)據(jù)結(jié)構(gòu),用于提高數(shù)據(jù)查詢的效率,加快數(shù)據(jù)檢索的速度。索引基于樹結(jié)構(gòu)實(shí)現(xiàn),可以通過B+樹等算法來優(yōu)化索引效率。MySQL中常見的索引類型包括主鍵索引、唯一索引、普通索引、全文索引等2023-04-04mysql8.0 windows x64 zip包安裝配置教程
這篇文章主要為大家詳細(xì)介紹了mysql8.0 windows x64 zip包安裝配置教程,具有一定的參考價值,感興趣的小伙伴們可以參考一下2018-05-05MySQL數(shù)據(jù)庫 1067錯誤號的解決方法
這篇文章主要介紹了MySQL數(shù)據(jù)庫 1067錯誤號的解決方法,非常不錯,具有參考借鑒價值,需要的朋友可以參考下2016-12-12Window環(huán)境下MySQL?UDF提權(quán)
本文章僅記錄某次內(nèi)網(wǎng)滲透過程中遇到的MySQL?采用UDF提權(quán)等方式進(jìn)行獲取權(quán)限,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧<BR>2023-03-03