设计 MySQL 表结构时，字符串字段类型的选择往往被新手忽视，却直接影响存储空间、索引性能和数据一致性。CHAR 类型用于存储固定长度字符串，VARCHAR 用于存储可变长度字符串，两者完全可以出现在同一张表中，关键在于理解它们的存储机制差异，并根据业务特征合理分配。本文将从底层存储原理、实际建表方案、常见踩坑点三个层面展开分析。
一、CHAR 与 VARCHAR 的存储原理差异
CHAR(N) 中的 N 表示字符数（不是字节数），MySQL 会严格按照这个长度存储数据。当插入的字符串不足 N 个字符时，MySQL 自动在尾部填充空格，取出来的时候再把尾部空格去掉（默认 sql_mode 下如此）。这意味着无论你存的是 1 个字符还是 10 个字符，CHAR(10) 占用的空间都一样。这种特性让它特别适合存储手机号、身份证号、国家代码、订单状态码这类长度稳定的字段。
VARCHAR(N) 则采用变长存储，实际占用空间由两部分组成：真实数据长度加上 1 到 2 个字节的长度前缀。N 不超过 255 时用 1 个字节记录长度，超过 255 时用 2 个字节。比如 VARCHAR(100) 存一个 5 字符的字符串，只占用 5 个字符的实际空间加 1 字节前缀。这种设计在字段长度波动较大时能显著节省磁盘空间，像地址、备注、用户昵称等字段用 VARCHAR 更合适。
需要注意两者在比较语义上的差别：CHAR 尾部填充的空格在比较和排序时会被忽略，而 VARCHAR 存储的尾部空格是保留的（部分排序校对规则下除外）。另外在内存临时表或者 Memory 引擎中，VARCHAR 会被当作 CHAR 处理，可能造成内存占用偏高，这是许多资料很少提到的细节。
二、同一张表中混用的建表实践
实际业务中，一张表几乎必然同时包含定长和变长字段。以一个典型的用户表为例，手机号固定 11 位适合 CHAR(11)，性别代码固定 1 位适合 CHAR(1)，而昵称、邮箱、地址长度不定，应该用 VARCHAR。下面是一个完整的建表语句：
CREATE TABLE `user_info` ( `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键', `mobile` CHAR(11) NOT NULL COMMENT '手机号，固定11位', `id_card` CHAR(18) DEFAULT NULL COMMENT '身份证号，固定18位', `gender` CHAR(1) DEFAULT '0' COMMENT '性别代码', `nickname` VARCHAR(50) NOT NULL COMMENT '昵称，长度不定', `email` VARCHAR(100) DEFAULT NULL COMMENT '邮箱', `address` VARCHAR(255) DEFAULT NULL COMMENT '地址', PRIMARY KEY (`id`), UNIQUE KEY `uk_mobile` (`mobile`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';
这个例子展示了混用的标准姿势：确定长度的字段用 CHAR 并给出精确长度，不确定的字段用 VARCHAR 并预留合理上限。utf8mb4 字符集下一个字符最多占 4 个字节，CHAR(11) 实际最大可能占用 44 字节，VARCHAR 的行大小限制是 65535 字节，这个限制针对整行所有列的总和，设计长字段较多的表时务必留意。
关于长度上限的选择还有个常见疑问：VARCHAR 是不是越长越好？从磁盘存储看，实际占用只和真实数据相关，设 VARCHAR(50) 和 VARCHAR(255) 存同一个 10 字符的字符串空间开销几乎一样。但影响有三点：一是更长的上限会拉大索引内存临时表的占用；二是校验约束变弱，脏数据更容易混进来；三是某些复制和内存分配场景会按最大长度预估。因此建议按业务真实上限设置，而不是无脑给 255。
三、常见踩坑点与性能考量
第一个坑是尾部空格问题。向 CHAR(5) 插入字符串 'abc'，查询时条件写 WHERE col = 'abc ' 或 'abc' 都能匹配上，因为尾部空格被忽略。但 VARCHAR 字段存入 'abc ' 后，用 'abc' 去查是查不到的，尾随空格算作数据的一部分。如果业务上有清洗需求，建议在应用层或用 TRIM 函数处理后再入库，避免出现隐性的数据不一致。
第二个坑是频繁更新的代价。当 VARCHAR 字段被更新为更长的值且当前页空间不足时，InnoDB 可能产生行迁移或页分裂，写放大随之增加。CHAR 由于空间恒定，更新时长度不变就没有这个问题。所以对于高频更新的定长字段，CHAR 反而更稳定。来看一个验证尾部空格行为的例子：
-- 创建测试表，同时包含两种类型
CREATE TABLE t_str (
c_char CHAR(5),
c_varchar VARCHAR(5)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
INSERT INTO t_str VALUES ('abc', 'abc');
-- CHAR 列尾部空格被忽略，能查到
SELECT * FROM t_str WHERE c_char = 'abc ';
-- VARCHAR 列尾部空格参与比较，查不到
SELECT * FROM t_str WHERE c_varchar = 'abc ';
-- 查看实际存储长度差异
SELECT c_char, CHAR_LENGTH(c_char), c_varchar, CHAR_LENGTH(c_varchar) FROM t_str;第三个考量是索引效率。CHAR 定长的索引键长度一致，缓存友好，范围扫描和前缀匹配表现稳定；VARCHAR 索引键长度随内容变化，统计信息估算有时不够精准。不过在现代 InnoDB 实现下，只要字段设置合理，两者查询性能差距在多数场景中可以忽略，真正该关注的反而是字符集选择和是否真的需要把长字符串字段建索引。总结起来：长度恒定且短的用 CHAR，长度波动或较长的用 VARCHAR，两者混用没有任何障碍，规范设计才是关键。
MySQL字符串存储CHAR和VARCHAR区别表结构设计修改时间：2026-09-04 22:28:37