MySQL 的 utf8 存不了 emoji，utf8mb4 到底要改哪几处

ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
SET NAMES utf8mb4;
-- JDBC URL
-- ?useUnicode=true&characterEncoding=utf8

用户昵称里带表情符号，保存时直接报错或变成问号，改成 utf8mb4 还是不行。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。

追下去是这么回事：MySQL 的 utf8 实际是三字节实现，存不下四字节字符，且连接层字符集也要一起改。

「MySQL utf8mb4emoji」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。

把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。改完隔一天再看一次，当场正常不代表能稳住。

测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。

处理上按这个顺序：改表与列的字符集；改连接字符集；确认客户端与驱动声明一致。

确认没问题再收工，表情符号能正常写入并原样读出，页面展示无乱码。