如何应对MySQL 8.0升级后默认字符集改为utf8mb4带来的存储空间增长

MySQL 8.0 升级后 utf8mb4 不会自动导致存储空间翻倍，仅在使用 4 字节字符、表重写、行格式不兼容或索引超限时才可能引发隐式膨胀或建表失败。

MySQL 8.0 升级后 utf8mb4 不会自动导致存储空间翻倍，但字段定义不当或索引配置遗漏时，确实可能引发隐式膨胀甚至建表失败。

utf8mb4 本身不增加已存数据体积

utf8mb4 是 utf8mb3（即 MySQL 的 utf8）的超集，对 ASCII 字符（如英文、数字、标点）仍用 1 字节存储；常见中文 UTF-8 编码为 3 字节，在 utf8mb4 下**完全不变**。只有真正使用 4 字节字符（如 ?、?‍?）时，才多占 1 字节——绝大多数存量数据不受影响。

常见误解是“VARCHAR(255) 在 utf8mb4 下必然占满 1020 字节”，实际只按内容动态分配，LENGTH() 和 CHAR_LENGTH() 可验证：前者返回字节数，后者返回字符数，两者在纯 ASCII 或 BMP 中文场景下相等。

真正导致空间增长的三个关键点

• ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 会重写整张表，触发 InnoDB 页重组，可能暂时增加碎片和磁盘占用（尤其大表），但不是编码本身所致
• 未启用 innodb_large_prefix + ROW_FORMAT=DYNAMIC 时，InnoDB 为兼容旧限制，可能将原本紧凑的行格式（如 COMPACT）升级为更松散的格式，间接增大单行平均体积
• 显式声明过长的 VARCHAR（如 VARCHAR(1000)）且字段实际只存短文本，InnoDB 的行溢出机制（off-page storage）在 utf8mb4 下更容易被触发，导致额外的指针开销和二级页分配

避免无效膨胀的实操建议

重点不在“缩容”，而在“不给膨胀机会”：

• 不要盲目执行 CONVERT TO，先用 SHOW CREATE TABLE 确认字段是否真含 CHARACTER SET utf8；若只是 DEFAULT CHARSET=utf8mb4 但字段没显式声明，实际已是 utf8mb4，无需转换
• 对已有表，优先用 ALTER TABLE t MODIFY c VARCHAR(N) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci 替代 CONVERT TO，它只改字段定义，不重写全表数据
• 建新表时明确指定 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) 改成 VARCHAR(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，而你还在查磁盘空间。