MySQL 8.0 emoji 存储需客户端、连接、服务端、库、表、字段六层字符集与校对规则全为 utf8mb4 和 utf8mb4_0900_ai_ci，缺一不可；仅改 my.cnf 中 character-set-server 不足，须同步配置 [client]、[mysql]、[mysqld] 段并显式升级已有对象及应用连接参数。
MySQL 8.0 的 character-set-server 默认确实是 utf8mb4，但这不等于你的 Emoji 能存进去、应用不报 Incorrect string value——真正生效要靠客户端、连接、服务端、库、表、字段六层全部对齐，缺一不可。
为什么改了 my.cnf 还是存不了 emoji
常见现象是：配置文件写了 character-set-server = utf8mb4，重启后 SHOW VARIABLES LIKE 'character_set_server' 显示正确，但插入 '?' 仍失败。
根本原因在于：MySQL 启动时只设定了“新建库/表的默认值”，而连接建立时的三要素——character_set_client、character_set_connection、character_set_results——全由客户端握手决定。如果应用没声明 charset=utf8mb4，或命令行工具没读对配置段，这三项就可能还是 utf8（即 utf8mb3）甚至 latin1。
-
[client]段必须加default-character-set = utf8mb4，否则mysql、mysqldump等工具默认按旧规则解析输入 -
[mysql]段也得加同样配置，专管mysql命令行客户端自身——不加它，你敲的 emoji 在终端里就被截断了 -
[mysqld]段除了character-set-server，必须配collation-server = utf8mb4_0900_ai_ci（MySQL 8.0+ 推荐），且建议加上init_connect = 'SET NAMES utf8mb4'，让普通用户连接后自动对齐会话层 - Linux 下用
mysql -u root -p连，若显示via socket，说明跳过了[client]段——此时要确认是否用了--defaults-file或路径权限问题
验证是否真生效，不能只看 server 变量
重启 MySQL 后，登录执行：
SHOW VARIABLES LIKE 'character\_set%';
必须同时满足以下四项全为 utf8mb4：
character_set_clientcharacter_set_connectioncharacter_set_resultscharacter_set_server
任一项是 utf8 或 latin1，说明某处配置未加载。典型原因包括：[mysqld_safe] 写成 [mysqld]、Docker 容器内 my.cnf 权限不是 644、Windows 下实际加载的是 C:\ProgramData\MySQL\my.ini 而非安装目录下的文件。
额外检查：SHOW VARIABLES LIKE 'collation%'; 确认 collation_server 是 utf8mb4_0900_ai_ci，不是 utf8mb4_unicode_ci（虽可用，但 8.0+ 默认和推荐是前者）。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
已有库表必须手动升级，CONVERT TO 不一定全覆盖
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci; 只改库默认值，不影响已有表；ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 看似全转，但若字段定义里硬编码了 CHARACTER SET utf8，MySQL 会优先信任字段级定义，跳过该字段。
安全做法是分层显式覆盖：
- 先改库：
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci; - 再改表：
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE = utf8mb4_0900_ai_ci; - 最后查字段：
SHOW CREATE TABLE tbl_name;确认每个文本字段的定义里明确写了CHARACTER SET utf8mb4，而不是留空或写utf8 - 若有字段仍不对，单独改列：
ALTER TABLE tbl_name MODIFY column_name TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
注意：含索引的 VARCHAR 字段在 utf8mb4 下最大长度受限（如 VARCHAR(255) × 4 字节 = 1020 字节），超 InnoDB 单索引长度限制（767 字节）会报 Specified key was too long。此时需配合 ROW_FORMAT=DYNAMIC 和 innodb_large_prefix=ON（MySQL 5.7+ 默认开启，8.0 已移除该参数，但需确认表格式）。
应用连接串必须显式声明 charset=utf8mb4
即使服务端和客户端配置全对，应用层不声明字符集，照样乱码。不同驱动写法不同：
- JDBC：
jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8mb4 - Python
pymysql：charset='utf8mb4'参数传入connect() - Node.js
mysql2："charset": "utf8mb4"放在连接配置对象里 - PHP PDO：
charset=utf8mb4加在 DSN 末尾，或PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"
特别注意：不要在连接后执行 SET NAMES utf8，那会把会话降级回 3 字节；也不要在代码里写 SET CHARACTER SET utf8——这两条都会覆盖前面所有配置。
最隐蔽的坑是：配置文件改对了、SQL 语句也跑了，但某个字段的 collation 还是 utf8mb4_unicode_ci，而其他都是 utf8mb4_0900_ai_ci。这种混合校对在 JOIN 或 ORDER BY 时可能触发隐式转换，导致索引失效或结果异常——统一校对规则比统一字符集更难被发现，也更值得花时间扫一遍。
