MySQL數據庫中CHAR與VARCHAR之爭

【引言】在數據庫中,字符型的數據是最多的,可以佔到整個數據庫的80%以上。爲此正確處理字符型的數據,對於提高數據庫的性能有很大的作用。在字符型數據中,用的最多的就是CharVarchar兩種類型。前面的是固定長度,而後面的是可變長度。現在我們需要考慮的是,在什麼情況下使用Char字符型數據,什麼情況下采用Varchar字符型數據。在這部分內容中,我就跟大家來探討一下這個話題。

一、VARCHARCHAR字符型數據的差異

 

MySQL數據庫中,用的最多的字符型數據類型就是VarcharChar.。這兩種數據類型雖然都是用來存放字符型數據,但是無論從結構還是從數據的保存方式來看,兩者相差很大。而且其具體的實現方式,還依賴於存儲引擎。我這裏就以大家最常用的MYISAM存儲引擎爲例,談談這兩種數據類型的差異。在後續建議中,也是針對這種存儲類型而言的。

 

這裏首先需要明白的一點是,這兩種數據類型,無論採用哪一種存儲引起,系統存儲數據的方式都是不同的。正是因爲如此,我們纔有必要研究兩者的不同。然後在合適的情況下,採用恰當的方式。瞭解這一點之後,我們再來看後續的內容。

 

Varchar往往用來保存可變長度的字符串。簡單的說,我們只是給其固定了一個最大值,然後系統會根據實際存儲的數據量來分配合適的存儲空間。爲此相比CHAR字符數據而言,其能夠比固定長度類型佔用更少的存儲空間。不過在實際工作中,由於某系特殊的原因,會在這裏設置例外。如管理員可以根據需要指定ROW_FORMAT=FIXED選項。利用這個選項來創建MyISAM表的話,系統將會爲每一行使用固定長度的空間。此時會造成存儲空間的損耗。通常情況下,VARCHAR數據類型能夠節約磁盤空間,爲此往往認爲其能夠提升數據庫的性能。不過這裏需要注意的是,這往往是一把雙刃劍。其在提升性能的同時,往往也會產生一些副作用。如因爲其長度是可變的,爲此在數據進行更新時可能會導致一些額外的工作。如在更改前,其字符長度是10(Varchar規定的最長字符數假設是50),此時系統就只給其分配10個存儲的位置(假設不考慮系統自身的開銷)。更改後,其數據量達到了20位。由於沒有超過最大50位的限制,爲此數據庫還是允許其存儲的。只是其原先的存儲位置已經無法滿足其存儲的需求。此時系統就需要進行額外的操作。如根據存儲引擎不同,有的會採用拆分機制,而有的則會採用分頁機制。

 

 

CHAR數據類型與VARCHAR數據類型不同,其採用的是固定長度的存儲方式。簡單的說,就是系統總爲其分配最大的存儲空間。當數據保存時,即使其沒有達到最大的長度,系統也會爲其分配這麼多的存儲空間。顯然,這種存儲方式會造成磁盤空間的浪費。這裏筆者需要提醒的一點是,當字符位數不足時,系統並不會採用空格來填充。相反,如果在保存CHAR值的時候,如果其後面有空值,系統還會自動過濾其空格。而在進行數據比較時,系統又會將空格填充到字符串的末尾。

 

顯然,VARCHARCHAR兩種字符型數據類型相比,最大的差異就是前者是可變長度,而後者則是固定長度。在存儲時,前者會根據實際存儲的數據來分配最終的存儲空間。而後者則不管實際存儲數據的長度,都是根據CHAR規定的長度來分配存儲空間。這是否意味着CHAR的數據類型劣於VARCHAR?其實不然。否則的話,就沒有必要存在CHAR字符類型了。雖然VARCHAR數據類型可以節省存儲空間,提高數據處理的效率。但是其可變長度帶來的一些負面效應,有時候會抵消其帶來的優勢。爲此在某些情況下,還是需要使用Char數據類型。

二、項目建議

 

根據上面的分析,我們知道VARCHAR數據類型是一把雙刃劍,其在帶來性能提升的同時,也可能會存在着一些額外的消耗。我們在評估到底是使用VARCHAR數據類型還是採用CHAR數據類型時,就需要進行均衡。在實際項目中,我們會考量如下情況。

一是根據字符的長度來判斷。如某個字段,像人的名字,其最長的長度也是有限的。如我們給其分配18個字符長度即可。此時雖然每個人的名字長度有可能不同,但是即使爲其分配了固定長度的字符類型,即18個字符長度,最後浪費的空間也不是很大。而如果採用NVARCHAR數據類型時,萬一以後需要改名,而原先的存儲空間不足用來容納新的值,反而會造成一些額外的工作。在這種情況下,進行均衡時,會認爲採用CHAR固定長度的數據類型更好。在實際項目中,如果某個字段的字符長度比較短此時一般是採用固定字符長度。

 

二是考慮其長度的是否相近。如果某個字段其長度雖然比較長,但是其長度總是近似的,如一般在90個到100個字符之間,甚至是相同的長度。此時比較適合採用CHAR字符類型。比較典型的應用就是MD5哈希值。當利用MD5哈希值來存儲用戶密碼時,就非常使用採用CHAR字符類型。因爲其長度是相同的。另外,像用來存儲用戶的身份證號碼等等,一般也建議使用CHAR類型的數據。

 

另外請大家考慮一個問題,CHAR(1)VARCHAR(1)兩這個定義,會有什麼區別呢?雖然這兩個都只能夠用來保存單個的字符,但是VARC HAR要比CHAR多佔用一個存儲位置。這主要是因爲使用VARCHAR數據類型時,會多用1個字節用來存儲長度信息。這個管理上的開銷CHAR字符類型是沒有的。

 

三是從碎片角度進行考慮。使用CHAR字符型時,由於存儲空間都是一次性分配的。爲此某個字段的內容,其都是存儲在一起的。單從這個角度來講,其不存在碎片的困擾。而可變長度的字符數據類型,其存儲的長度是可變的。當其更改前後數據長度不一致時,就不可避免的會出現碎片的問題。故使用可變長度的字符型數據時,數據庫管理員要時不時的對碎片進行整理。如執行數據庫導出導入作業,來消除碎片。

 

四是即使使用Varchar數據類型,也不能夠太過於慷慨。這是什麼意思呢?如現在用戶需要存儲一個地址信息。根據評估,只要使用100個字符就可以了。但是有些數據庫管理員會認爲,反正Varchar數據類型是根據實際的需要來分配長度的。還不如給其大一點的呢。爲此他們可能會爲這個字段一次性分配200個字符的存儲空間。這VARCHAR(100)VARCHAR(200)真的相同嗎?結果是否定的。雖然他們用來存儲90個字符的數據,其存儲空間相同。但是對於內存的消耗是不同的。對於VARCHAR數據類型來說,硬盤上的存儲空間雖然都是根據實際字符長度來分配存儲空間的,但是對於內存來說,則不是。其時使用固定大小的內存塊來保存值。簡單的說,就是使用字符類型中定義的長度,即200個字符空間。顯然,這對於排序或者臨時表(這些內容都需要通過內存來實現)作業會產生比較大的不利影響。所以如果某些字段會涉及到文件排序或者基於磁盤的臨時表時,分配VARCHAR數據類型時仍然不能夠太過於慷慨。還是要評估實際需要的長度,然後選擇一個最長的字段來設置字符長度。如果爲了考慮冗餘,可以留10%左右的字符長度。千萬不能認爲其爲根據實際長度來分配存儲空間,而隨意的分配長度,或者說乾脆使用最大的字符長度。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章