如何正确配置MySQL 8.0的字符集为utf8mb4来支持表情存储？

MySQL 8.0 表情存不进的根本原因是连接层、库、表、字段、索引格式六处未全部对齐 utf8mb4，需逐层检查并显式设置 charset=utf8mb4、ALTER DATABASE/TABLE/MODIFY COLUMN、启用 innodb_large_prefix 及 ROW_FORMAT=DYNAMIC。

MySQL 8.0 默认已是 utf8mb4，但你的表情依然存不进去——问题几乎一定出在连接层、表结构或字段定义没同步升级。

为什么 INSERT INTO users (name) VALUES ('?') 还是报 Incorrect string value

MySQL 8.0 的 character_set_server 默认确实是 utf8mb4，但这只影响新创建的数据库；已有库、表、列仍沿用旧字符集（比如 utf8 或 utf8mb3）。更关键的是：character_set_client、character_set_connection、character_set_results 这三项必须也都是 utf8mb4，否则客户端发来的 4 字节 Emoji 在解析阶段就被截断了。

验证方式：登录 MySQL 后执行

SHOW VARIABLES LIKE 'character_set%';

如果其中任意一项显示 utf8（不是 utf8mb4），就说明连接握手没走对路。

• 检查应用连接串是否显式声明了 charset=utf8mb4（JDBC 加 ?useUnicode=true&characterEncoding=utf8mb4）
• 确认没有在连接后执行 SET NAMES utf8 这类覆盖操作
• 宝塔面板用户注意：[client] 段落必须手动补上 default-character-set = utf8mb4，否则 phpMyAdmin 或命令行客户端默认仍按 utf8 解析

ALTER TABLE CONVERT TO CHARACTER SET utf8mb4 为什么没生效

这条语句看似把表转完了，但实际可能跳过字段——尤其当字段定义里硬编码了 CHARACTER SET utf8。MySQL 会优先信任字段级定义，忽略表级转换指令。

正确做法是分层确认并显式覆盖：

• 数据库级：ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;（MySQL 8.0+ 推荐用 _0900_ai_ci）
• 表级：ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
• 字段级（关键！）：ALTER TABLE tbl_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;，不能只靠 CONVERT

执行后用 SHOW CREATE TABLE tbl_name; 看建表语句，确认字段定义里明确写了 CHARACTER SET utf8mb4，而不是留空或写 utf8。

加了 utf8mb4 却提示 Specified key was too long

这是 utf8mb4 下最隐蔽的翻车点：一个 VARCHAR(191) 字段在 utf8mb4 下最大占 764 字节（191×4），刚好卡在 InnoDB 默认索引长度上限（767 字节）边缘；一旦字段更长或有多个索引列，就会触发该错误。

必须同时满足以下条件才能支持长字段建索引：

• innodb_file_format = Barracuda（MySQL 5.7.7+ 已弃用，但低版本或自定义配置可能还关着）
• innodb_file_per_table = ON
• innodb_large_prefix = ON（MySQL 5.7.7+ 默认开启，但某些云 RDS 实例需手动打开参数）
• 建表或转换时指定 ROW_FORMAT=DYNAMIC，例如：ALTER TABLE tbl_name ROW_FORMAT=DYNAMIC;

漏掉任一条件，CONVERT TO 可能静默失败——表结构看起来改了，实际字段仍是 utf8 编码，Emoji 插入时照样报错。

真正麻烦的从来不是改配置，而是你得一层层确认：服务端、连接层、数据库、表、字段、索引格式，六处都得对齐 utf8mb4，缺一不可。尤其是字段定义里那个藏得很深的 CHARACTER SET utf8，不手动重写就永远绕不开。