sql,char,varchar

 

http://www.chinaz.com/program/2011/0503/176896.shtml

---

 

在數據庫中，字符型的數據是最多的，能夠佔到整個數據庫的80%以上。爲此正確處理字符型的數據，對於提升數據庫的性能有很大的做用。在字符型數據中，用的最多的就是Char與Varchar兩種類型。前面的是固定長度，然後面的是可變長度。如今咱們須要考慮的是，在什麼狀況下使用Char字符型數據，什麼狀況下采用Varchar字符型數據。在這部份內容中，我就跟你們來探討一下這個話題。

1、VARCHAR與CHAR字符型數據的差別

在MySQL數據庫中，用的最多的字符型數據類型就是Varchar和Char.。這兩種數據類型雖然都是用來存放字符型數據，可是不管從結構仍是從數據的保存方式來看，二者相差很大。並且其具體的實現方式，還依賴與存儲引擎。我這裏就以你們最經常使用的MYISAM存儲引擎爲例，談談這兩種數據類型的差別。在後續建議中，也是針對這種存儲類型而言的。

這裏首先須要明白的一點是，這兩種數據類型，不管採用哪種存儲引發，系統存儲數據的方式都是不一樣的。正是由於如此，咱們纔有必要研究二者的不一樣。而後在合適的狀況下，採用恰當的方式。瞭解這一點以後，咱們再來看後續的內容。

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

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

顯然，VARCHAR與CHAR兩種字符型數據類型相比，最大的差別就是前者是可變長度，然後者則是固定長度。在存儲時，前者會根據實際存儲的數據來分配最終的存儲空間。然後者則無論實際存儲數據的長度，都是根據CHAR規定的長度來分配存儲空間。這是否意味着CHAR的數據類型劣於VARCHAR呢？其實否則。不然的話，就沒有必要存在CHAR字符類型了。雖然VARCHAR數據類型能夠節省存儲空間，提升數據處理的效率。可是其可變長度帶來的一些負面效應，有時候會抵消其帶來的優點。爲此在某些狀況下，仍是須要使用Char數據類型。

2、項目建議

根據上面的分析，咱們知道VARCHAR數據類型是一把雙刃劍，其在帶來性能提高的同時，也可能會存在着一些額外的消耗。咱們在評估究竟是使用VARCHAR數據類型仍是採用CHAR數據類型時，就須要進行均衡。在實際項目中，咱們會考量以下狀況。

一是根據字符的長度來判斷。如某個字段，像人的名字，其最長的長度也是有限的。如咱們給其分配18個字符長度便可。此時雖然每一個人的名字長度有可能不一樣，可是即便爲其分配了固定長度的字符類型，即18個字符長度，最後浪費的空間也不是很大。而若是採用NVARCHAR數據類型時，萬一之後須要更名，而原先的存儲空間不足用來容納新的值，反而會形成一些額外的工做。在這種狀況下，進行均衡時，會認爲採用CHAR固定長度的數據類型更好。在實際項目中，若是某個字段的字符長度比較短此時通常是採用固定字符長度。

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

另外請你們考慮一個問題，CHAR（1）與VARCHAR（1）兩這個定義，會有什麼區別呢？雖然這兩個都只可以用來保存單個的字符，可是VARCHAR要比CHAR多佔用一個存儲位置。這主要是由於使用VARCHAR數據類型時，會多用1個字節用來存儲長度信息。這個管理上的開銷CHAR字符類型是沒有的。

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

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