MySQL中文乱码需统一客户端、服务端、数据库、表、字段五层字符集为utf8mb4，因其支持4字节Unicode字符（如Emoji、生僻字），而旧utf8仅支持3字节；配置、表结构、应用连接三方面必须同步修改，否则仍会乱码。
直接说结论：MySQL中文乱码不是“修一个地方就能好”的问题，而是客户端、服务端、数据库、表、字段五层字符集不一致导致的。只改 my.ini 或只执行 ALTER TABLE 都可能漏掉关键环节；必须统一用 utf8mb4，且要覆盖全部五层。
为什么 utf8 不行，必须用 utf8mb4
MySQL 的 utf8 是个历史包袱——它实际是 utf8mb3，最多只支持 3 字节编码，无法存储 Emoji、部分生僻汉字（如「?」「?」）、以及 newer Unicode 字符。当你看到 Incorrect string value: '\xF0\x9F\x98\x80' for column 这类错误，就是典型的 4 字节 UTF-8 字符被截断了。
而 utf8mb4 是真正完整的 UTF-8 实现，兼容所有 Unicode 字符，且向后兼容 utf8。MySQL 5.5.3+ 默认支持，现在新项目没理由再用 utf8。
-
utf8mb4必须配合utf8mb4_unicode_ci或utf8mb4_0900_as_cs（MySQL 8.0+ 推荐）排序规则，避免大小写/重音处理异常 - 旧配置里写
default-character-set=utf8或character-set-server=utf8的，必须改成utf8mb4，否则无效 -
SET NAMES utf8要同步改为SET NAMES utf8mb4，否则客户端连接仍走 3 字节路径
五层字符集必须全部对齐
执行 SHOW VARIABLES LIKE 'character%'; 会返回至少 7 行，其中关键的是这 5 个：
-
character_set_client：客户端发来的 SQL 语句按什么编码解析 -
character_set_connection：SQL 解析过程中临时转换用的编码（通常和 client 一致） -
character_set_database：当前默认数据库的字符集（建库时指定，可被 ALTER 修改） -
character_set_results：查询结果返回给客户端时用的编码 -
character_set_server：服务端默认字符集，影响新建库/表的默认值
只要其中任意一层是 latin1 或 utf8，就可能在某条链路上把中文或 Emoji 截断。例如：客户端用 utf8mb4 发送，但 character_set_connection 是 utf8，MySQL 就会在解析时丢掉第 4 字节。
实操：从配置到表结构一次性对齐
分三步，缺一不可：
-
改配置文件（
my.iniWindows //etc/mysql/my.cnfLinux）：在[mysqld]下加character-set-server = utf8mb4collation-server = utf8mb4_unicode_ci
在[client]和[mysql]下都加default-character-set = utf8mb4 - 重启 MySQL 服务**后**，确认生效：
SHOW VARIABLES LIKE 'character%';—— 上述 5 项必须全为utf8mb4 - 批量修正已有库表**（不能跳过）**：
ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：CONVERT TO会重定义所有VARCHAR/TEXT字段的字符集，但不会改列定义里的CHARACTER SET显式声明（如有），建议顺手检查并显式补上
应用连接也要同步改
即使服务端全配对了，Java、Python、Node.js 等客户端仍可能用错编码。常见错误：
- JDBC URL 漏参数：
jdbc:mysql://host:3306/db?useUnicode=true&characterEncoding=utf8mb4（注意是utf8mb4，不是UTF-8或utf8） - Python PyMySQL / mysql-connector-python 忘设
charset='utf8mb4' - PHP PDO DSN 缺
;charset=utf8mb4 - 命令行客户端（
mysql -u root -p）启动后立刻执行SET NAMES utf8mb4;，否则默认仍可能走utf8
最容易被忽略的一点：如果表里已有乱码数据（比如存成了 æ），单纯改字符集不会恢复原文——那是损坏后的字节流，必须从源头重新导入。
