转至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
