轉至http://blog.csdn.net/hjm4702192/article/details/8434919
前言：
相信大家都用過這兩種類型，可能覺得它們兩個太像了，好像沒有什么區別，用這兩個都可以存文字和數字還有空格和標點符號。在設計數據庫的時候，也的確不太能區分什么時候用CHAR，什么時候用VARCHAR.
今天就詳細的查看和測試了一下這兩個字段，并記錄下來了。相信也會給大家一個很好的參考。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
CHAR和VARCHAR類型類似，但它們保存和檢索的方式不同。它們的最大長度和是否尾部空格被保留等方面也不同。在存儲或檢索過程中不進行大小寫轉換。CHAR和VARCHAR類型聲明的長度表示你想要保存的最大字符數。例如，CHAR(30)可以占用30個字符。 CHAR列的長度固定為創建表時聲明的長度。長度可以為從0到255的任何值。當保存CHAR值時，在它們的右邊填充空格以達到指定的長度。當檢索到CHAR值時，尾部的空格被刪除掉。在存儲或檢索過程中不進行大小寫轉換。VARCHAR列中的值為可變長字符串。長度可以指定為0到65,535之間的值。(VARCHAR的最大有效長度由最大行大小和使用的字符集確定。整體最大長度是65,532字節）。同CHAR對比，VARCHAR值保存時只保存需要的字符數，另加一個字節來記錄長度(如果列聲明的長度超過255，則使用兩個字節)。VARCHAR值保存時不進行填充。當值保存和檢索時尾部的空格仍保留，符合標準SQL。如果分配給CHAR或VARCHAR列的值超過列的最大長度，則對值進行裁剪以使其適合。如果被裁掉的字符不是空格，則會產生一條警告。如果裁剪非空格字符，則會造成錯誤(而不是警告)并通過使用嚴格SQL模式禁用值的插入。參見5.3.2節，“SQL服務器模式”。下面的表顯示了將各種字符串值保存到CHAR(4)和VARCHAR(4)列后的結果，說明了CHAR和VARCHAR之間的差別：
請注意上表中最后一行的值只適用不使用嚴格模式時；如果MySQL運行在嚴格模式，超過列長度不的值不保存，并且會出現錯誤。 從CHAR(4)和VARCHAR(4)列檢索的值并不總是相同，因為檢索時從CHAR列刪除了尾部的空格。通過下面的例子說明該差別：
mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.02 sec)
mysql> INSERT INTO vc VALUES ('ab ', 'ab ');
Query OK, 1 row affected (0.00 sec)
mysql> SELECT CONCAT(v, '+'), CONCAT(c, '+') FROM vc;
+----------------+----------------+
| CONCAT(v, '+') | CONCAT(c, '+') |
+----------------+----------------+
| ab + | ab+ |
+----------------+----------------+
1 row in set (0.00 sec)
根據分配給列的字符集校對規則對CHAR和VARCHAR列中的值進行排序和比較。 請注意所有MySQL校對規則屬于PADSPACE類。這說明在MySQL中的所有CHAR和VARCHAR值比較時不需要考慮任何尾部空格。例如：
mysql> CREATE TABLE names (myname CHAR(10), yourname VARCHAR(10));
Query OK, 0 rows affected (0.09 sec)
mysql> INSERT INTO names VALUES ('Monty ', 'Monty '); Query OK, 1 row affected (0.00 sec)
mysql> SELECT myname = 'Monty ', yourname = 'Monty ' FROM names;
+--------------------+----------------------+
| myname = 'Monty ' | yourname = 'Monty ' |
+--------------------+----------------------+
| 1 | 1 |
+--------------------+----------------------+
1 row in set (0.00 sec)
請注意所有MySQL版本均如此，并且它不受SQL服務器模式的影響。 對于尾部填充字符被裁剪掉或比較時將它們忽視掉的情形，如果列的索引需要唯一的值，在列內插入一個只是填充字符數不同的值將會造成復制鍵值錯誤。 CHAR BYTE是CHAR BINARY的別名。這是為了保證兼容性。 ASCII屬性為CHAR列分配latin1字符集。UNICODE屬性分配ucs2字符集。
總結來說：
在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數據類型。
項目建議
根據上面的分析，我們知道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%左右的字符長度。千萬不能認為其為根據實際長度來分配存儲空間，而隨意的分配長度，或者說干脆使用最大的字符長度。
補充
在MySQL中用來判斷是否需要進行對據列類型轉換的規則 １、在一個數據表里，如果每一個數據列的長度都是固定的，那么每一個數據行的長度也將是固定的． ２、只要數據表里有一個數據列的長度的可變的，那么各數據行的長度都是可變的． ３、如果某個數據表里的數據行的長度是可變的，那么，為了節約存儲空間，MySQL會把這個數據表里的固定長度類型的數據列轉換為相應的可變長度類型．例外：長度小于４個字符的char數據列不會被轉換為varchar類型 對于MyISAM表，盡量使用Char，對于那些經常需要修改而容易形成碎片的myisam和isam數據表就更是如此，它的缺點就是占用磁盤空間； 對于InnoDB表，因為它的數據行內部存儲格式對固定長度的數據行和可變長度的數據行不加區分（所有數據行共用一個表頭部分，這個標頭部分存放著指向各有關數據列的指針），所以使用char類型不見得會比使用varchar類型好。事實上，因為char類型通常要比varchar類型占用更多的空間，所以從減少空間占用量和減少磁盤i/o的角度，使用varchar類型反而更有利.文章2：字符應該是最常見的一種了，但似乎各個數據庫都有所不同，比如Oracle中就有啥varchar2之類。不過mysql似乎最多的還是集中在char和varchar上。說說區別。char是固定長度的，而varchar會根據具體的長度來使用存儲空間。比如char(255)和varchar(255)，在存儲字符串"hello world"的時候，char會用一塊255的空間放那個11個字符，而varchar就不會用255個，他先計算長度后只用11個再加上計算的到字符串長度信息，一般1-2個byte來，這樣varchar在存儲不確定長度的時候會大大減少存儲空間。如此看來varchar比char聰明多了，那char有用武之地嗎？還是很不少優勢的。一，存儲很短的信息，比如門牌號碼101，201……這樣很短的信息應該用char，因為varchar還要占個byte用于存儲信息長度，本來打算節約存儲的現在得不償失。二，固定長度的。比如使用uuid作為主鍵，那用char應該更合適。因為他固定長度，varchar動態根據長度的特性就消失了，而且還要占個長度信息。三，十分頻繁改變的column。因為varchar每次存儲都要有額外的計算，得到長度等工作，如果一個非常頻繁改變的，那就要有很多的精力用于計算，而這些對于char來說是不需要的。還有一個關于varchar的問題是，varchar他既然可以自動適應存儲空間，那我varchar(8)和varchar(255)存儲應該都是一樣的，那每次表設計的時候往大的方向去好了，免得以后不夠用麻煩。這個思路對嗎？答案是否定的。mysql會把表信息放到內存中（查詢第一次后，就緩存住了，Linux下很明顯，但windows下似乎沒有，不知道為啥），這時內存的申請是按照固定長度來的，如果varchar很大就會有問題。所以還是應該按需索取。
總結：仔細看DZ的數據表，定長的字段基本還都是用char....
詳細出處參考：http://www.jb51.NET/article/23575.htm
