首先给出结论：MySQL 8.0 将默认字符集升级为 utf8mb4 后，已有数据的字节数并不会自动翻倍。真正需要警惕的是遇到 4 字节字符、表重写、行格式不兼容或索引超限等情况时，才可能出现隐式膨胀或建表失败。然而，在日常开发中，最常见的错误其实是字段定义或索引配置不当。
升级后存储空间暴涨的说法，其实多半是把简单问题复杂化了。但如果没有提前规划好字段和索引，确实容易踩到几个常见陷阱。
utf8mb4 本身不会增加已有数据的存储体积
utf8mb4 是 utf8mb3（即旧版 MySQL 中的 utf8）的超集。凭借天然的兼容性，绝大多数常见字符的存储方式完全不变：ASCII 字符（英文、数字、标点）仍然只占 1 字节，中文 UTF-8 编码在两种字符集下都是 3 字节。只有当你真正遇到 4 字节字符（比如 emoji 或一些生僻文字）时，才会多占用 1 字节——但这类字符在绝大多数业务数据中占比极低。
一个常见的误解是：VARCHAR(255) 在 utf8mb4 下会固定占用 1020 字节。实际上，MySQL 对这些字段的内容是按需动态分配空间的。使用 LENGTH() 和 CHAR_LENGTH() 分别查看字节数和字符数，很容易验证：只要存储的内容是纯 ASCII 或常用中文，两者相等，说明字节数没有变化。
真正导致空间增长的三个关键因素
那最可能出现空间膨胀的地方是哪里呢？主要逃不出这三处：
- 表重写操作——执行
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4时，InnoDB 会重写整张表并重新组织页结构。对于大表，临时磁盘碎片和额外占用确实会增加。但需要明确：问题出在“重写”过程，与字符集本身无关。 - 行格式不兼容——如果没有同时启用
innodb_large_prefix和ROW_FORMAT=DYNAMIC，旧表可能被迫从原来的紧凑型 COMPACT 行格式“升级”到更松散的格式，导致单行占用的平均体积自然增大。 - 过长 VARCHAR 字段溢出——比如声明了 VARCHAR(1000) 但实际只存储几十个字符，InnoDB 的行溢出机制（off-page storage）更容易被触发。额外的二级页分配和指针开销，也会增加整体存储空间。
避免存储膨胀的实用建议
正确的思路是“不给膨胀留机会”，而不是事后想办法“缩容”。
- 不要盲目执行
CONVERT TO。先使用SHOW CREATE TABLE查看字段的字符集声明——如果只是表默认字符集改为 utf8mb4，而字段定义未显式更改，很可能它们已经是 utf8mb4，无需转换。 - 对于已有表，优先使用
ALTER TABLE t MODIFY c VARCHAR(N) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci。该语句只修改字段定义，不涉及整表数据，效率更高。 - 创建新表时，务必明确指定
ROW_FORMAT=DYNAMIC，并确认innodb_file_format为 Barracuda（MySQL 5.7.7 及以上版本默认开启，但自建 Docker 或旧配置可能遗漏）。 - 定期检查
information_schema.INNODB_SYS_TABLES中的ROW_FORMAT和FILE_FORMAT。如果发现Antelope，应立即处理——这是旧格式，不仅不支持超过 767 字节的索引，还更容易产生冗余填充。
索引长度超限才是“伪空间问题”的罪魁祸首
实际上，在开发过程中最容易踩的坑是索引超限错误。遇到 Specified key was too long 时，千万不要以为是磁盘空间不足。它只是 InnoDB 优雅地拒绝创建长度超过限制的索引。接着被迫削减字段长度，例如从 VARCHAR(255) 减到 191，导致语义表达力下降，有时还会引发业务逻辑漏洞。
对应的正确做法很简单：
- 确认
innodb_large_prefix=ON（MySQL 8.0 默认开启，如果不放心可重启后检查一次） - 确保表使用
ROW_FORMAT=DYNAMIC（执行一条ALTER TABLE t ROW_FORMAT=DYNAMIC;即可） - 避免在 utf8mb4 字段上创建全文索引或极长前缀索引（例如
INDEX(col(255))），改用更精确的前缀长度（例如col(191)仅在必须兼容旧驱动时保留）。
这些配置中任何一项遗漏，CONVERT TO 都可能静默失败——表面上表结构变了，实际上字段仍然是 utf8mb3。等到某天插入 emoji 时，等待你的依然是熟悉的 Incorrect string value 错误。而你却还在对着磁盘空间百思不得其解。
