mysql 8.0 默认使用 utf8mb4 是为支持 emoji 等 4 字节字符，避免 incorrect string value 错误；但因 utf8mb4 单字符占 4 字节，varchar(255) 索引达 1020 字节，超出 innodb 默认 767 字节限制，需显式设 row_format=dynamic 并确保 innodb_file_per_table=on 才能启用 3072 字节大前缀支持。
MySQL 8.0 默认用 utf8mb4，不是为了“更先进”，而是因为旧的 utf8（实际是 utf8mb3）根本存不了 emoji、生僻汉字、越南语多音符字——一插就报 Incorrect string value。但这个“补全”动作直接撞上了 InnoDB 的索引长度机制，问题不在字符集本身，而在字节膨胀后和底层限制的冲突。
为什么 utf8mb4 字段加索引会报 Specified key was too long
错误不是随机出现的，它只在满足以下条件时触发：
-
innodb_large_prefix = OFF（MySQL 5.7.7 之前默认关，部分 5.7 定制环境或低配 Docker 镜像仍可能关着） - 表未显式指定
ROW_FORMAT=DYNAMIC或ROW_FORMAT=COMPRESSED - 字段定义长度 × 4 > 767 字节（例如
VARCHAR(255)→ 最多占 1020 字节）
关键点：InnoDB 单列索引键前缀默认上限是 767 字节。而 utf8mb4 下每个字符最多占 4 字节，所以 VARCHAR(191) 是安全边界（191 × 4 = 764 ≤ 767），VARCHAR(192) 就可能越界。联合索引则按所有列字节总和算，更容易超。
MySQL 8.0 真的“默认解决”了这个问题吗？
不完全。虽然 MySQL 8.0 移除了 innodb_large_prefix 参数、默认启用大前缀支持（单列索引上限升至 3072 字节），但有两个隐藏前提：
- 表必须使用
Barracuda文件格式（innodb_file_format已废弃，但底层仍依赖） - 表空间必须是独立的（
innodb_file_per_table = ON，8.0 默认开，但若从老版本升级且未重建表，可能沿用共享表空间）
最典型的翻车场景：用 ALTER TABLE ... CONVERT TO CHARSET utf8mb4 迁移老表，却没加 ROW_FORMAT=DYNAMIC。结果表结构显示改了，SHOW CREATE TABLE 里仍见 ROW_FORMAT=Compact，索引还是走 767 字节逻辑，静默失败。
建表或迁移时必须显式控制的三个参数
别信“默认已好”，尤其跨版本迁移或容器部署。每次建表或转换都应手动确认：
- 加
ROW_FORMAT=DYNAMIC（COMPRESSED也可，但压缩有 CPU 开销） - 确保
innodb_file_per_table = ON（查SELECT @@innodb_file_per_table） - 对 MySQL 5.7.7–5.7.30，显式设
innodb_large_prefix = ON（8.0 不需，但配置文件里留着也无害）
正确建表示例：
CREATE TABLE users (<br> id BIGINT PRIMARY KEY,<br> nickname VARCHAR(255) NOT NULL,<br> INDEX idx_nickname (nickname)<br>) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC;
最容易被忽略的兼容性断层
开发本地是 MySQL 8.0，跑得通 VARCHAR(255) 加索引；但上线到客户现场的 MySQL 5.6 或某些云厂商定制版 5.7（关闭了 innodb_large_prefix），同一语句直接报错。这种差异不会在语法检查阶段暴露，只在 CREATE TABLE 或 ALTER TABLE ADD INDEX 时炸。真正的坑不在字符集，而在你没意识到：同一个 DDL，在不同实例上可能走完全不同的索引长度校验路径。
