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，不手动重写就永远绕不开。
