char和varchar這兩種類型是我們經常使用的類型，在使用的時候大家也沒有特別注意有什麼區別，好奇心驅使我對其進行探究，經過查閱一番資料手冊以及做的小測試，有了一定程度的瞭解，特此記錄下來！
手冊中有提到：CHAR和VARCHAR類型類似，但它們保存和檢索的方式不同。它們的最大長度和是否尾部空格被保留等方面也不同。在存儲或檢索過程中不進行大小寫轉換。
稍微進一步的解釋:
char和varchar類型聲明長度表示用戶想保存的最大字符數，其中char(M)定義的列的長度爲固定的，M的取值可以0-255之間，當保存char值時，在它們的右邊填充空格以達到指定的長度。當檢索到char值時，尾部的空格被刪除掉（如下圖）。在存儲或檢索過程中不進行大小寫轉換。char存儲定長數據很方便，char字段上的索引效率很高。
varchar(M)定義的列的長度是可變長度字符串，在MySQL5.0以上的版本中，varchar的數據類型長度支持到了65535，因爲起始位和結束位佔去了3個字節，所以其整體最大長度爲65532字節（varchar的最大有效長度由最大行大小和使用的字符集確定）。
除此之外，與char比，varchar值保存時只保存需要的字符數，另加一個字節來記錄長度（長度超過255時需要2個字節）。
同樣在char和varchar尾部加空格，檢索時char類型後的被刪掉，而varchar類型的保存。
總結：
在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數據類型，也不能夠太過於慷慨。這是什麼意思呢?如現在用戶需要存儲一個地址信息。根據評估，只要使用100個字符就可以了。但是有些數據庫管理員會認爲，反正Varchar數據類型是根據實際的需要來分配長度的。還不如給其大一點的呢。爲此他們可能會爲這個字段一次性分配200個字符的存儲空間。這VARCHAR(100)與VARCHAR(200)真的相同嗎?結果是否定的。雖然他們用來存儲90個字符的數據，其存儲空間相同。但是對於內存的消耗是不同的。對於VARCHAR數據類型來說，硬盤上的存儲空間雖然都是根據實際字符長度來分配存儲空間的，但是對於內存來說，則不是。其實使用固定大小的內存塊來保存值。簡單的說，就是使用字符類型中定義的長度，即200個字符空間。顯然，這對於排序或者臨時表(這些內容都需要通過內存來實現)作業會產生比較大的不利影響。所以如果某些字段會涉及到文件排序或者基於磁盤的臨時表時，分配VARCHAR數據類型時仍然不能夠太過於慷慨。還是要評估實際需要的長度，然後選擇一個最長的字段來設置字符長度。如果爲了考慮冗餘，可以留10%左右的字符長度。千萬不能認爲其爲根據實際長度來分配存儲空間，而隨意的分配長度，或者說乾脆使用最大的字符長度。
適用情況：
1、對於MyISAM表，儘量使用Char，對於那些經常需要修改而容易形成碎片的myisam和isam數據表就更是如此，它的缺點就是佔用磁盤空間；
2、對於InnoDB表，因爲它的數據行內部存儲格式對固定長度的數據行和可變長度的數據行不加區分（所有數據行共用一個表頭部分，這個標頭部分存放着指向各有關數據列的指針），所以使用char類型不見得會比使用varchar類型好。事實上，因爲char類型通常要比varchar類型佔用更多的空間，所以從減少空間佔用量和減少磁盤i/o的角度，使用varchar類型反而更有利；
3、存儲很短的信息，比如門牌號碼101，201……這樣很短的信息應該用char，因爲varchar還要佔個byte用於存儲信息長度，本來打算節約存儲的現在得不償失。
4、固定長度的。比如使用uuid作爲主鍵，那用char應該更合適。因爲他固定長度，varchar動態根據長度的特性就消失了，而且還要佔個長度信息。
5、十分頻繁改變的column。因爲varchar每次存儲都要有額外的計算，得到長度等工作，如果一個非常頻繁改變的，那就要有很多的精力用於計算，而這些對於char來說是不需要的。