MySQL里到底该选char还是varchar，这两个类型的优缺点和适用场景怎么抉择呢？

在MySQL里设计数据库表的时候，对于字符串类型的字段，CHAR和VARCHAR是最常被拿来比较和选择的两个类型，很多人刚开始会纠结到底用哪个，其实只要理解了它们最根本的区别，选择起来就清晰多了，这个根本区别就是存储和检索的方式不同。

CHAR类型：定长字符串

你可以把CHAR类型想象成一个长度固定的盒子，比如你定义了一个CHAR(10)，那么无论你往里面放几个字，哪怕是只放一个字母“A”，MySQL也会在硬盘上预留出整整10个字符的空间，如果内容不够10个字符，MySQL会自动用空格在右边填充到指定的长度，当你读取这个数据的时候，MySQL又会自动把这些填充的空格去掉,再把内容还给你。

CHAR的优点：

1. 性能极高（在特定场景下）： 这是CHAR最大的优势，因为每个数据项的长度都是已知且固定的，所以数据库可以非常快速地定位和读取数据，想象一下，如果一条记录中的所有字符串字段都是定长的，MySQL计算某一行数据的位置会非常简单直接，就像在操场上做广播体操，每个人的间距都一样，教官一眼就能找到第几排第几个是谁，这对于那些长度变化很小或者基本不变的字段来说，能带来性能上的提升，存储用户的性别（M/F）、固定的状态码（如‘ACTV’、‘INAC’）、国家代码（如‘CN’、‘US’）等,CHAR非常高效。
2. 简单可靠： 由于是固定长度，没有额外的计算开销,在处理上更简单。

CHAR的缺点：

1. 浪费存储空间： 这是它最明显的缺点，如果你用CHAR(100)来存储用户的邮箱地址，但大部分邮箱可能只有20-30个字符，那么每个邮箱记录都会浪费掉70-80个字符的空间，对于数据量巨大的表，这种空间浪费是惊人的，不仅增加了存储成本，也会导致数据页能容纳的行数变少，可能反而会影响查询效率（因为需要读取更多的数据页）。

VARCHAR类型：变长字符串

VARCHAR则像一个弹性伸缩的袋子，你定义的是最大长度，比如VARCHAR(100)，表示这个袋子最多能装100个字符，但实际存储时，它只占用实际内容长度加上一点点额外字节（用来记录内容长度信息）的空间，存“A”就只占很少的空间,存满100个字符就占用100个字符加上额外字节的空间。

VARCHAR的优点：

1. 节省存储空间： 这是VARCHAR最核心的优势，它按需分配空间，极大地减少了存储空间的浪费，这对于长度变化很大的数据来说至关重要，比如用户的姓名、地址、产品描述、文章标题等，节省空间也意味着在同样的磁盘空间里能存储更多的数据，缓冲池（内存）中可以缓存更多的数据行,从而提升整体性能。

VARCHAR的缺点：

1. 有轻微的性能开销： 因为每个VARCHAR字段的长度不确定，所以在读取时需要先检查记录长度的额外字节，才能知道这个字段到底有多长，这个开销在现代数据库系统中通常非常小，除非是在极端高性能要求的场景下,否则几乎可以忽略不计。
2. 可能产生碎片： 由于长度可变，当频繁更新VARCHAR字段并且导致数据长度发生变化时（比如把一个短地址更新成一个长地址），可能会产生更多的存储碎片，偶尔会需要执行OPTIMIZE TABLE来重整表空间,但这也是可管理的。

如何抉择？适用场景是什么？

根据上面的优缺点,选择规则其实很清晰：

优先选择CHAR的场景：

• 存储的字符串长度非常固定且短小。 这是黄金法则，典型的例子包括：
  • MD5哈希值： 固定是32个字符。
  • 身份证号： 固定18位字符。
  • UUID： 虽然较长（36字符），但如果经常基于它进行查询，且长度绝对固定，CHAR(36)可能比VARCHAR(36)稍快。
  • 各种枚举代码、状态码： 比如订单状态（‘PAID’，‘SENT’）、性别（‘M’，‘F’）、省份缩写等。

优先选择VARCHAR的场景：

• 存储的字符串长度变化很大，或者平均长度远小于定义的最大长度。 这是最常见的情况，绝大多数字符串字段都属于这一类，例子包括：
  • 用户名、昵称
  • 电子邮件地址
  • 、摘要
  • 用户地址、备注信息
  • 几乎任何用户自由输入的文本字段。

一个重要的补充和常见误区

根据MySQL官方文档的说明，有一个值得注意的点：在InnoDB存储引擎下，如果一条记录中所有的列都是固定长度的（比如全是CHAR和数字类型），那么InnoDB会将其视为固定长度的记录，但只要表中存在哪怕一个可变长度的列（如VARCHAR、TEXT、BLOB），InnoDB就会将整条记录视为可变长度记录，这意味着，在你已经使用了VARCHAR的表中，将某个短字段从VARCHAR(10)改为CHAR(10)所带来的性能收益可能会比预期小得多，因为整行记录的处理方式已经是可变长的了,这个细节让VARCHAR的适用性变得更加广泛。

总结一下

选择的关键在于长度的可预测性。

• 如果你能百分之百确定这个字段的长度就是那么几个字符，雷打不动，比如像身份证号，那就用CHAR,效率最高。
• 如果你不确定长度，或者长度变化范围很大，比如用户名、地址，那么毫无疑问应该选择VARCHAR，它能为你节省大量空间,而空间在现代数据库设计中往往比那一点点微乎其微的计算开销更重要。

在实践中，除非有非常明确的理由（存储固定长度的代码），否则更推荐使用VARCHAR，因为它更灵活,在大多数现实场景中更能节省资源。