ALTER TABLE 时必须同时指定 charset 和 collation，仅改其一无效；需确保表、字段、连接、服务端配置四层 utf8mb4 全面生效，否则 emoji 插入失败或静默截断。
ALTER TABLE 时 charset 和 collation 要一起改，只改一个没用
MySQL 的字符集和排序规则是绑定生效的。只执行 ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4，表结构可能变成 utf8mb4，但字段实际还是 utf8mb4_general_ci 或更老的 utf8mb4_unicode_ci —— 这本身不算错，但如果你后续要存 emoji，得确保 collation 支持四字节排序（比如 utf8mb4_0900_as_cs 或至少 utf8mb4_unicode_ci）。更稳妥的是显式指定两者：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;- 如果用的是 MySQL 8.0+，推荐
utf8mb4_0900_as_cs（大小写敏感 + 口音敏感），避免模糊匹配问题 - 注意：
CONVERT TO会重建整张表，大表务必在低峰期操作，并确认磁盘空间足够
字段级编码没改？SHOW CREATE TABLE 一眼就能发现
改完表级 charset，字段可能还卡在 utf8 或 utf8mb3。常见现象是插入 emoji 报错：Incorrect string value: '\xF0\x9F\x98\x80' for column 'name' at row 1。这不是服务器或连接层的问题，就是字段自己没升级。
- 先查现状：
SHOW CREATE TABLE t;，看每个VARCHAR字段声明里有没有CHARACTER SET utf8mb4 - 单独改字段：
ALTER TABLE t MODIFY COLUMN name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 别漏掉
TEXT、TINYTEXT等类型，它们同样需要显式指定CHARACTER SET - 如果字段有索引且长度超 191，记得检查
innodb_large_prefix和行格式（MySQL 5.7+ 默认ROW_FORMAT=DYNAMIC才支持长索引）
客户端连接不配 utf8mb4，改了表也白搭
表和字段都对了，但应用连进来用的是 utf8 连接（实际是 utf8mb3），MySQL 会自动截断四字节字符，不报错也不警告，只是静默丢掉 emoji 后半部分。
- 连接时必须带参数：
?charset=utf8mb4（PHP PDO）、charset=utf8mb4（Python MySQLdb）、或在 JDBC URL 加useUnicode=true&characterEncoding=utf8mb4 - 验证是否生效：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;三个值都应为utf8mb4 - 如果用 ORM（如 Django、Laravel），别只改数据库配置，还要确认其连接初始化 SQL 里有没有
SET NAMES utf8mb4
mysqld 配置项不全开，ALTER 操作可能中途失败
即使你手敲命令成功，如果 MySQL 服务端没配好，新插入数据仍可能被转义或截断，尤其涉及 JSON 字段或全文索引时。
- 必须检查并设置以下三项（在
my.cnf的[mysqld]段）：character-set-server = utf8mb4、collation-server = utf8mb4_unicode_ci、skip-character-set-client-handshake（强制客户端服从服务端设定） -
max_allowed_packet建议 ≥ 64M，否则含大量 emoji 的批量 INSERT 可能被截断 - 重启 mysqld 后，用
mysql --defaults-file=/etc/my.cnf -e "SELECT @@character_set_server;"确认生效
最常被忽略的是：改完配置没重启 MySQL，或者只改了 client 段没动 mysqld 段。表可以改，但下次重启服务，连接默认又退回到 utf8。
