VARCHAR和CHAR是两种最主要的字符串类型。 不幸的是，很难准确解释这些值是如何存储在磁盘和内存中的。 这是因为它涉及这个冰存储引擎的具体实现。 以下说明假设您要使用的存储引擎是InnoDB和/或My ISAM。 如果这两个存储引擎都未使用，请参阅您的存储引擎文档。
首先，我们来看看VARC HAR和C HA R的值通常如何存储在磁盘上。 请注意，MySQL服务器可能需要将从存储引擎读取的值转换为其他存储格式，因为存储引擎保存CHA R或VARC HAR值的方式在内存和磁盘上可能不同。 以下是两种类型的比较。
VARCHAR
VARCHAR类型用于存储可变长度字符串，是最常见的字符串数据类型。 比起定长型
因为只使用所需的空间，所以可以节约空间。 例如，越短的字符串越不使用空格。 有例外。 如果MySQL表是用ROW_FORMAT=FIXED创建的，则每行都使用固定长度的存储，会浪费空间。
VARCHAR要求额外记录一个或两个字节的字符串长度。 如果列的最大长度小于或等于255字节，则只使用1字节的表示，否则使用2字节。 如果使用latinl字符集，则VARC焊盘r(10 )的列需要11字节的存储空间。 VARC焊盘r(1000 )列需要1002字节，因为它需要2字节的内存长度信息。
VARCHAR为了节约存储容量，也有助于性能。 但是，由于行会变长，因此在更新时行可能会比原来长，需要额外的工作。 如果一行占用的空间增加，页面中可以保存的空间不增加，则不同的存储引擎的处理方式也不同。 例如，MyISAM必须将行拆分为单独的碎片存储器，而InnoDB必须拆分页面以使行适合页面。 其他一些存储引擎不会在原始数据的位置更新数据。
在以下情况下使用VARCHAR是合适的： 字符串列的最大长度比平均长度大得多$列的更新很少，因此碎片不是问题。 p使用复杂的字符集，如UTF-8，每个字符以不同的字节数存储。
从5.0版开始，MySQL在保存和检索时保留尾部空格。 但是，在4.1之前的版本中，MySQL会删除尾部空格。
InnoDB更灵活，可以将过长的VARC陆r保存为BLOB。 关于这个问题稍后说明。
CHAR
CHAR型是固定长度。 MySQL始终根据定义的字符串的长度分配足够的空间。 保存CHAR值时，MySQL会删除末尾的所有空格。 在MySQL4.1之前的版本中，VARCHA也是这样实现的。 这意味着，在这些版本中，CHAR和VARCHAR不仅在存储格式上相同，在逻辑上也相同。 C陆r值根据需要用空格填充，便于比较。
CHAR适用于存储短字符串或所有值都接近相同长度的情况。 例如，CHAR最适合存储密码的q05值。 这是固定长度的值。 对于频繁更改的数据，CHAR也优于VARCHAR。 这是因为固定长度的CHAR类型很难碎片化。 对于非常短的列，CHARVARCHAR还可以更有效地利用存储空间。 例如，要只存储y和n的值，请使用char(L )。 例如，单字节字符集注5只需要一个字节，而VARC焊盘r ) l )需要两个字节。 这是因为还有记录长度的额外字节。
CHAR类型的这些行为可能有点难懂，我将通过具体的例子来说明。 首先，创建只有一个C阳刚10 )字段的表井，并在其中插入一些值。
搜索这些值时，您会发现string3末尾的空格被截断了。
在varchar(10 )字段中存储相同的值将产生以下结果：
存储数据的方式因存储引擎而异，并非所有存储引擎都以相同的方式处理固定长度和较长的字符串。 Memory引擎只支持固定长度的行，即使长度增加，也会根据最大长度分割字段
分配最大的空间。 但是，填充和剪切空格的行为在MySQL服务器层处理，因此因存储引擎而异。
与CHAR和VARCHAR类似的类型有存储二进制字符串的BINARY和VARBINARY。 二进制字符串ii的普通字符串非常相似，但二进制字符nance存储的是字节码而不是字符。 填充也不同。 MySQL填充BINARY使用的是0(0)而不是空格。 此外，搜索时也不会突然删除填充值。
当需要存储二进制数据、井井有条且MySQL需要使用字节码而不是字符进行比较时，这些类型非常有用。 二进制比较的优点不仅仅是大小写的敏感性。 MySQL在比较BINARY字符串时，每次按一个字节，然后根据该字节的数值进行比较。 因此，二进制比较比字符简单得多，所以更快。