MySQL手册中有提到：CHAR和VARCHAR类型类似，但它们保存和检索的方式不同。它们的最大长度以及是否保留尾部空格等方面也不同，在存储或检索过程中不进行大小写转换
用户定义数据时，char和varchar类型长度表示想保存的最大字符数，其中char(M)定义的列的长度为固定的，M的取值可以0-255之间，保存char类型数据时，在它们的右边填充空格以达到指定的长度。当检索到char值时，尾部的空格被删除掉。在存储或检索过程中不进行大小写转换，char存储定长数据很方便，char字段上的索引效率很高。
varchar(M)定义的列的长度是可变长度字符串，在MySQL5.0以上的版本中，varchar的数据类型长度支持到了65535，因为起始位和结束位占去了3个字节，所以其用于存储数据的最大长度为65532字节（varchar的最大有效长度由最大行大小和使用的字符集确定）
除此之外，varchar值保存时只保存数据部分，不用和char一样填充空格，此外另加一个字节来记录长度（长度超过255时需要2个字节），检索时char类型后的空格被删掉，而不会删除varchar类型后的空格
在MySQL数据库中，用的最多的字符型数据类型就是VARCHAR和CHAR。这两种数据类型虽然都是用来存放字符型数据，但是无论从结构还是从数据的保存方式来看，两者相差很大。而且其具体的实现方式，还依赖于存储引擎。这里就以MYISAM存储引擎为例，谈谈这两种数据类型的差异
这里首先需要明白的一点是，这两种数据类型，无论采用哪一种存储引擎，系统存储VARCHAR和CHAR的方式都是不同的。正是因为如此，我们才有必要研究两者的不同。然后在合适的情况下，采用恰当的方式。
Varchar往往用来保存可变长度的字符串。简单的说，我们只是给其固定了一个最大值，然后系统会根据实际存储的数据量来分配合适的存储空间。因此相比CHAR字符数据而言，其能够比固定长度类型占用更少的存储空间。不过在实际工作中，由于某些特殊的原因，会在这里设置例外。如管理员可以根据需要指定ROW_FORMAT=FIXED选项。利用这个选项来创建MyISAM表的话，系统将会为每一行使用固定长度的空间，此时会造成存储空间的损耗。
通常情况下，VARCHAR数据类型能够节约磁盘空间，因此往往认为其能够提升数据库的性能。不过这里需要注意的是，这往往是一把双刃剑。其在提升性能的同时，往往也会产生一些副作用。如因为其长度是可变的，数据更新时可能会导致一些额外的工作。比如在更改前，其字符长度是10位(假设用户指定VARCHAR的最大长度为50)，此时系统就只给其分配10个存储的位置(假设不考虑系统自身的开销)。更改后，其数据量达到了20位。由于没有超过最大50位的限制，为此数据库还是允许其存储的。由于原先的存储位置已经无法满足其存储的需求，需要存储到另一片大内存中，此时系统就需要进行额外的操作。如根据存储引擎不同，有的会采用拆分机制，而有的则会采用分页机制
CHAR数据类型与VARCHAR数据类型不同，其采用的是固定长度的存储方式。简单的说，就是系统总为其分配最大的存储空间。当数据保存时，即使其没有达到最大的长度，系统也会为其分配这么多的存储空间。显然，这种存储方式会造成磁盘空间的浪费
显然，VARCHAR与CHAR两种字符型数据类型，最大的差异就是VARCHAR是可变长度，而CHAR则是固定长度。在存储时，VARCHAR会根据实际存储的数据来分配最终的存储空间。而CHAR则不管实际存储数据的长度，都是根据规定的长度来分配存储空间。这是否意味着CHAR的数据类型劣于VARCHAR呢?其实不然。否则的话，就没有必要存在CHAR字符类型了。虽然VARCHAR数据类型可以节省存储空间，提高数据处理的效率。但是其可变长度带来的一些负面效应，有时候会抵消其带来的优势。为此在某些情况下，还是需要使用CHAR数据类型
注意：使用VARCHAR数据类型，也不能够太过于慷慨。这是什么意思呢?如现在用户需要存储一个地址信息。根据评估，只要使用100个字符就可以了。但是有些数据库管理员会认为，反正Varchar数据类型是根据实际的需要来分配长度的，还不如给其大一点的呢。为此可能会为这个字段一次性分配200个字符的存储空间。
这VARCHAR(100)与VARCHAR(200)真的相同吗?结果是否定的。虽然他们用来存储90个字符的数据，其存储空间相同，但消耗的内存是不同的。对于VARCHAR数据类型来说，硬盘上的存储空间虽然都是根据实际字符长度来分配存储空间的，但是对于内存来说，则不是。其实使用固定大小的内存块来保存值。
简单的说，就是使用字符类型中定义的长度，即200个字符空间。显然，这对于排序或者临时表(这些内容都需要通过内存来实现)作业会产生比较大的不利影响。所以如果某些字段会涉及到文件排序或者基于磁盘的临时表时，分配VARCHAR数据类型时仍然不能够太过于慷慨。还是要评估实际需要的长度，然后选择一个最长的字段来设置字符长度。如果为了考虑冗余，可以留10%左右的字符长度。千万不能认为其为根据实际长度来分配存储空间，而随意的分配长度，或者说干脆使用最大的字符长度。
适用情况：
- 对于MyISAM表，尽量使用CHAR，对于那些经常需要修改而容易形成碎片的数据表就更是如此，它的缺点就是占用磁盘空间；
- 对于InnoDB表，因为它的数据行内部存储格式对固定长度的数据行和可变长度的数据行不加区分（所有数据行共用一个表头部分，这个标头部分存放着指向各有关数据列的指针），所以使用char类型不见得会比使用varchar类型好。事实上，因为char类型通常要比varchar类型占用更多的空间，所以从减少空间占用量和减少磁盘i/o的角度，使用varchar类型反而更有利；
- 存储很短的信息，比如门牌号码101，201……这样很短的信息应该用char，因为varchar还要使用1个字节用于存储信息长度，本来打算节约存储的现在得不偿失
- 固定长度的。比如使用uuid作为主键，那用char应该更合适。因为他固定长度，varchar动态根据长度的特性就消失了，而且还要占1个字节长度信息。
- 十分频繁改变的column。因为varchar每次存储都要有额外的计算，得到长度等工作，如果一个非常频繁改变的，那就要有很多的精力用于计算，而这些对于char来说是不需要的