MySQL中文乱码本质是客户端、连接层、表结构三层字符集不一致，必须统一为utf8mb4；重点检查character_set_client/connection/results，修改应用连接参数而非仅改表，用HEX()验证真实存储编码。
MySQL 中文乱码本质是客户端、连接层、表结构三层字符集不一致，只改 CREATE TABLE 的 CHARACTER SET 不解决问题。
检查当前各层字符集是否统一为 utf8mb4
乱码常发生在插入或查询时显示问号（???）或 Mojibake（如“æ‘们”），第一步不是改表，而是确认实际生效的字符集层级：
- 连接层：执行
SHOW VARIABLES LIKE 'character_set%';，重点看character_set_client、character_set_connection、character_set_results—— 这三个必须都是utf8mb4，否则即使表用utf8mb4也白搭 - 数据库/表级：用
SHOW CREATE DATABASE db_name;和SHOW CREATE TABLE tb_name;查看DEFAULT CHARSET和列定义里的CHARACTER SET - 注意：
utf8是 MySQL 的伪 utf8（最多 3 字节），不支持 emoji 和部分生僻中文；必须用utf8mb4
修改连接层字符集（最常被忽略的环节）
很多用户改完表仍乱码，是因为应用连接 MySQL 时没指定字符集，导致沿用服务器默认（常为 latin1）。解决方式取决于使用场景：
- 命令行客户端：启动时加参数
--default-character-set=utf8mb4，或在~/.my.cnf中写入：[client] default-character-set = utf8mb4
- PHP PDO：DSN 中显式声明
;charset=utf8mb4，例如mysql:host=localhost;dbname=test;charset=utf8mb4 - Java JDBC：URL 后追加
?characterEncoding=utf8mb4&serverTimezone=UTC - Python PyMySQL：初始化连接时传参
charset='utf8mb4'
安全迁移已有表到 utf8mb4
直接 ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4; 有风险，尤其当字段含 TEXT 或索引长度超限时：
- 先确认字段最大长度：MySQL
utf8mb4下，VARCHAR(255)实际占用字节数可能达 1020（255×4），而 InnoDB 单索引长度限制为 767 字节（旧版本）或 3072 字节（5.7+ +innodb_large_prefix=ON） - 若报错
Specified key was too long，需缩短字段长度，例如把VARCHAR(255)改成VARCHAR(191) - 推荐分步操作：
ALTER TABLE t MODIFY c VARCHAR(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，比CONVERT更可控 - 别漏掉
COLLATE——utf8mb4_unicode_ci比utf8mb4_general_ci更准（后者已弃用）
验证数据是否真正“存对了”
别只靠 SELECT 看显示结果。有些客户端（如旧版 phpMyAdmin）会自行转码，造成“看起来对，其实错了”的假象：
- 用十六进制查原始字节：
SELECT HEX(col_name) FROM t WHERE id = 1;，正确存储的中文应返回类似E4BDA0（“你”字 UTF-8 编码），而非C4E3（GB2312 错误编码） - 用命令行客户端直连验证，关闭所有中间层（如 ORM、Web 框架的自动转码）
- 如果
HEX()结果正常但 SELECT 显示乱码，问题一定出在客户端或连接层，和表结构无关
字符集问题最难调试的地方在于：它可能在任意一层断开，且错误表现高度相似。每次改动后，务必用 HEX() 和 SHOW VARIABLES 双重验证，而不是依赖肉眼观察。
