MySQL VARCHAR vs CHAR：深入理解差异 – wiki基地

---

MySQL VARCHAR vs CHAR：深入理解差异

在构建数据库时，选择合适的数据类型是至关重要的一步，它直接影响到数据库的存储效率、查询性能以及应用的健壮性。在 MySQL 中，对于存储字符串数据，最常用的两种数据类型莫过于 VARCHAR 和 CHAR。虽然它们都用于存储文本，但在存储方式、空间占用、性能表现以及对末尾空格的处理等方面存在显著差异。理解这些差异是进行高效数据库设计的基石。

本文将深入探讨 VARCHAR 和 CHAR 的区别，帮助读者根据实际需求做出明智的选择。

1. CHAR 数据类型是什么？

CHAR（Character）是一种固定长度的字符串类型。当你声明一个 CHAR(n) 类型的列时，n 表示该列能够存储的最大字符数。无论你实际存储的字符串长度是多少，该列总是会占用 n 个字符的存储空间。

存储方式和空间占用：

CHAR(n) 列在物理存储时，总是分配 n 个字符所需的字节空间。

• 如果实际存储的字符串长度小于 n，MySQL 会在字符串的末尾自动填充空格，直到其长度达到 n。
• 如果实际存储的字符串长度等于 n，则直接存储。
• 如果尝试存储的字符串长度大于 n，MySQL 会根据 SQL Mode 的设置进行处理。在严格模式下会报错，非严格模式下可能会被截断（这是不推荐的做法，应尽量避免）。

例如，一个声明为 CHAR(10) 的列：

• 存储 ‘abc’ 时，实际存储的是 ‘abc_‘ (其中’_’代表填充的空格)。占用的空间是 10 个字符所需的字节数。
• 存储 ‘abcdefghij’ 时，实际存储的是 ‘abcdefghij’。占用的空间是 10 个字符所需的字节数。

性能特点：

由于 CHAR 是固定长度的，其存储位置和大小都是预先确定的。这带来了以下潜在的性能优势：

1. 读写效率： 对于固定长度的字段，数据库系统可以更快速、更直接地定位和访问数据，因为不需要额外处理长度信息。
2. 索引效率： 如果将 CHAR 列作为索引键，固定长度的索引键使得索引结构（如 B-tree）更加紧凑和稳定，查找效率可能更高。
3. 内存处理： 在进行排序或在内存中处理数据时，固定长度的数据块处理起来相对简单。

末尾空格处理：

这是 CHAR 的一个重要特性，也是许多用户感到困惑的地方。当从 CHAR 列中检索数据时，MySQL 默认会移除末尾的填充空格。

• 如果你存储了 ‘abc’ (实际存储为 ‘abc_‘)，检索出来的会是 ‘abc’。
• 如果你存储了 ‘abc ‘ (假设有三个末尾空格)，实际存储会根据总长度填充，例如 CHAR(10) 会存储 ‘abc ____’，检索出来的会是 ‘abc’。

这意味着，对于 CHAR 类型，存储时末尾的空格在检索时会被忽略。如果你需要精确地保留末尾的空格，或者末尾空格对于你的数据有实际意义（例如密码哈希、某些编码），使用 CHAR 可能需要特别注意或不适合。当然，可以通过设置 SQL Mode PAD_CHAR_TO_FULL_LENGTH 来改变这种行为，但这通常不属于默认情况。

适用场景：

CHAR 类型适用于存储长度固定不变或变化非常小的数据，或者长度虽然可变但不超过很短的最大值，并且对性能要求非常高的场景。常见的用例包括：

• 国家代码 (如 ‘US’, ‘CN’)
• 性别代码 (如 ‘M’, ‘F’)
• 校验和或哈希值 (如 MD5 的 32 个字符)
• 状态标志 (如 ‘A’ 代表激活, ‘I’ 代表非激活)
• 邮政编码 (某些国家有固定长度)
• 固定长度的短代码或标识符

在这些场景下，使用 CHAR 可以确保数据对齐，简化存储和处理，并可能带来轻微的性能提升。

2. VARCHAR 数据类型是什么？

VARCHAR（Variable Character）是一种可变长度的字符串类型。当你声明一个 VARCHAR(n) 类型的列时，n 表示该列能够存储的最大字符数。与 CHAR 不同，VARCHAR 列占用的存储空间是根据实际存储的字符串长度来决定的，而不是固定的 n。

存储方式和空间占用：

VARCHAR(n) 列在存储时，实际占用的空间等于字符串本身的字节长度，外加一个或两个字节用于存储字符串的实际长度信息。

• 如果实际存储的字符串长度小于或等于 255 字节，需要额外 1 个字节来存储长度。
• 如果实际存储的字符串长度大于 255 字节，但小于或等于 65535 字节，需要额外 2 个字节来存储长度。

请注意，这里的长度是指字节数，而不是字符数。一个字符占用多少字节取决于使用的字符集（如 ASCII 占用 1 字节，UTF8mb4 可能占用 1-4 字节）。n 是最大字符数，MySQL 会根据字符集计算出 n 个字符可能占用的最大字节数，并确保其不超过行的总字节限制 (65535 字节) 和单个 VARCHAR 字段的限制。

例如，一个声明为 VARCHAR(10) 的列（使用 UTF8mb4 字符集）：

• 存储 ‘abc’ 时，实际存储的是长度信息 (1 字节) + ‘abc’ (3 字节)，总共占用 4 个字节。
• 存储 ‘abcdefghij’ 时，实际存储的是长度信息 (1 字节) + ‘abcdefghij’ (10 字节)，总共占用 11 个字节。
• 存储 ‘你好’ (假设每个汉字 3 字节) 时，实际存储的是长度信息 (1 字节) + ‘你好’ (6 字节)，总共占用 7 个字节。

性能特点：

VARCHAR 的可变长度特性带来了空间上的节省，但也可能引入一些性能上的复杂性：

1. 空间效率： 对于存储长度变化很大的数据，VARCHAR 可以显著节省存储空间，尤其是在有很多数据长度远小于最大长度的情况下。
2. 读写效率： 由于需要读取额外的长度信息才能确定字符串的实际结束位置，理论上比读取固定长度的 CHAR 略有开销。此外，变长记录在物理存储上可能导致行不对齐，增加 I/O 操作的复杂性。
3. 更新操作： 如果更新一个 VARCHAR 字段，新值比旧值长，并且当前页没有足够的空间容纳变长的记录，可能导致行迁移（row migration）或页分裂（page split），这会增加更新的开销。
4. 索引效率： 将 VARCHAR 列作为索引键，由于键长是可变的，索引结构相对不如固定长度的 CHAR 紧凑和稳定，在某些情况下（如频繁的更新导致键长变化）可能影响索引性能。排序时，处理变长字符串也可能比处理固定长度字符串稍微复杂。

末尾空格处理：

与 CHAR 相反，VARCHAR 在存储和检索时会保留末尾的空格。

• 如果你存储了 ‘abc’，检索出来的就是 ‘abc’。
• 如果你存储了 ‘abc ‘ (假设有三个末尾空格)，检索出来的就是 ‘abc ‘。

这意味着，对于 VARCHAR 类型，末尾空格是数据的一部分，会被精确地存储和检索。这更符合大多数情况下对字符串的处理需求。

适用场景：

VARCHAR 类型适用于存储长度变化较大，或者大部分数据长度都远小于设定的最大长度的字符串数据。这是最常用的字符串类型。常见的用例包括：

• 姓名
• 地址
• 文章标题
• 描述性文本
• 任意长度变化的标识符（如 UUID，虽然 UUID 长度固定，但 VARCHAR(36) 也是常用选择，因为它不会像 CHAR(36) 那样在某些非标准 UUID 表示时浪费空间，并且末尾空格处理更符合预期）
• 任意用户输入的文本内容

在绝大多数情况下，如果无法确定字符串的精确固定长度，或者长度变化较大，使用 VARCHAR 是更优的选择，因为它能有效地节省存储空间。

3. CHAR vs VARCHAR 详细对比总结

特性	CHAR(n)	VARCHAR(n)
存储方式	固定长度	可变长度 + 长度前缀 (1 或 2 字节)
空间占用	总是 n 个字符所需的字节空间	实际字符串字节长度 + 长度前缀所需的字节空间
空间效率	可能浪费空间 (若实际长度 < n)	节省空间 (若实际长度 < n)
末尾空格	存储时填充至 n，检索时默认移除末尾空格	存储和检索时保留末尾空格
最大长度 (n)	0 – 255 (受字符集和行总字节限制影响)	0 – 65535 (整个行总字节限制为 65535，包含所有列和开销)
读写性能	通常略快 (固定长度，直接存取)	通常略慢 (需读取长度信息)
更新性能	稳定 (固定长度，不易导致行迁移/页分裂)	若新值更长可能导致行迁移/页分裂，开销增加
索引性能	索引键固定长度，索引结构更紧凑稳定	索引键可变长度，结构可能不如 CHAR 稳定
内存处理	相对简单 (固定大小)	相对复杂 (可变大小)

关于最大长度 (n) 的补充说明：

• CHAR(n) 中的 n 最大值是 255。
• VARCHAR(n) 中的 n 最大值理论上可以达到 65535，但实际受限于 MySQL 的行总字节限制，即一个表的一行数据总共不能超过 65535 字节（不包括 TEXT/BLOB 类型的大对象）。VARCHAR 列的存储空间（字符串本身字节 + 1/2 字节长度前缀）会计入这个总限制。
• 使用多字节字符集（如 UTF8mb4，每个字符最多 4 字节）时，VARCHAR(n) 中的 n 实际能达到的最大字符数会减少。例如，VARCHAR(255) 在 ASCII 下最多存 255 字符 (255 字节 + 1 字节长度前缀 = 256 字节)，但在 UTF8mb4 下最多只能存 65535 / 4 ≈ 16383 个字符 (理论值，实际受限于 65535 的行限制)。一个 VARCHAR(255) 列如果用 UTF8mb4 存储，它可能占用多达 255 * 4 + 2 = 1022 字节。

4. 如何选择 CHAR 还是 VARCHAR？

在理解了 CHAR 和 VARCHAR 的差异后，选择哪种类型就取决于你的具体需求：

1. 数据的长度是固定不变的吗？

   • 是： 考虑使用 CHAR。例如，存储 MD5 哈希值 (32 个字符)、固定的两位国家代码等。CHAR 的固定长度优势在这里能体现。
   • 否： 几乎总是选择 VARCHAR。大多数字符串数据（姓名、地址、描述、文章标题等）的长度都是可变的，使用 VARCHAR 可以有效节省存储空间。

2. 是否关心末尾的空格？

   • 关心，需要精确保留末尾空格： 必须使用 VARCHAR。
   • 不关心，末尾空格无意义或应该被忽略： CHAR 的默认行为可能适合你，但即便如此，如果长度不是固定的，VARCHAR 仍然可能是更好的选择，因为它节省空间。在需要忽略末尾空格进行比较的场景下，即使使用 VARCHAR，也可以通过 TRIM() 函数或适当的比较操作来模拟 CHAR 的行为。

3. 性能是首要考虑因素吗？

   • 对于短且固定长度的字段，如果它们是核心查询或索引的关键部分，并且微小的性能差异至关重要，CHAR 可能提供略微的性能优势。
   • 对于大多数应用，VARCHAR 带来的空间节省以及处理可变长度数据的灵活性通常 outweighs 了与 CHAR 相比潜在的、微小的性能开销。过分追求 CHAR 的性能优势而牺牲空间效率，尤其是在数据长度不固定的情况下，往往得不偿失。

4. 最大可能长度是多少？

   • 如果最大长度非常小（例如小于 10-20 个字符），并且数据长度变化不大，CHAR 和 VARCHAR 的空间差异可能不那么显著，此时可以更多考虑末尾空格处理和固定长度带来的简单性。
   • 如果最大长度较大，或者实际数据长度变化很大，VARCHAR 的空间节省优势会非常明显。

一个常见的误区：

有人认为 VARCHAR 字段声明得越大越好，比如 VARCHAR(255) 或 VARCHAR(500)，即使实际数据长度很少超过几十。虽然 VARCHAR 只占用实际数据长度加额外字节，但声明过大的 VARCHAR 也会带来一些影响：

• 内存分配： MySQL 在执行某些操作（如创建内存表、排序、临时表）时，可能会根据列的最大长度分配内存空间。声明过大的 VARCHAR 可能导致不必要的内存浪费。
• 行大小限制： 虽然 VARCHAR 是变长的，但其声明的最大长度仍会影响行总字节数的计算，从而可能限制你在表中添加更多列或声明其他大字段。
• 可读性和维护性： 声明一个远超实际需求的长度，不利于理解数据模型的约束。

建议：

• 对于绝大多数需要存储字符串的场景，优先考虑使用 VARCHAR。
• 为 VARCHAR(n) 中的 n 选择一个合理的、基于实际数据需求的最大长度，而不是简单地使用一个大值（如 255）。预估一下你可能存储的最长字符串是多长，然后留一些余量。
• 仅在字符串长度严格固定不变，并且需要利用 CHAR 的固定长度特性或末尾空格默认处理方式时，才考虑使用 CHAR。

5. 额外的性能考量

虽然前面提到了性能，这里可以稍微展开：

• 磁盘 I/O： 变长记录可能导致数据页填充不均匀，更新时引起页分裂或行迁移，这些都会增加磁盘 I/O 操作，影响性能。固定长度的 CHAR 则没有这个问题。
• 缓存效率： 在 MySQL 的 Buffer Pool 中，固定长度的记录更容易管理和缓存。变长记录可能导致缓存碎片，降低缓存效率。
• 网络传输： 虽然现在网络带宽普遍很高，但在极端情况下，大量填充了空格的 CHAR 数据可能会比 VARCHAR 传输更多不必要的数据。但通常这不是主要考虑因素。

总的来说，这些额外的性能考量在大多数情况下对于 VARCHAR 和 CHAR 的选择影响不大，除非你在处理非常高吞吐量、对性能极其敏感的场景，并且数据特性（固定长度、短）恰好与 CHAR 的优势匹配。

6. 总结

VARCHAR 和 CHAR 是 MySQL 中用于存储字符串数据的两种基本类型。它们核心的区别在于存储方式（可变长度 vs 固定长度）以及对末尾空格的处理。

• CHAR 适用于存储固定长度或长度变化非常小的数据，它以空间换时间，可能在读写和索引固定长度数据时提供微弱的性能优势，但会填充和默认移除末尾空格。
• VARCHAR 适用于存储长度变化较大的数据，它以时间和少量额外存储（长度前缀）换取显著的空间节省，并保留末尾空格。它是更通用、更常用的字符串类型。

在实际应用中，理解数据的特性（长度是否固定、是否需要保留末尾空格）是选择合适数据类型的关键。对于绝大多数变长字符串数据，VARCHAR 是更明智和高效的选择。只有在数据长度严格固定，且需要利用固定长度带来的某些特定优势时，才考虑使用 CHAR。合理选择 VARCHAR 的最大长度，避免过度声明，也能帮助优化数据库的设计。

通过深入理解这两种类型的差异及其背后的原理，开发者能够构建出更高效、更健壮的数据库应用。

---