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，而你还在查磁盘空间。
