MySQL查询乱码根本原因是客户端、连接、服务端、表字段四层字符集不一致；须逐一检查并统一为utf8mb4，特别注意连接层三参数及字段级显式声明。
MySQL查询结果乱码，根本原因几乎总是客户端、连接、服务端、表字段四层字符集不一致，只改其中一层大概率无效。
检查当前各层字符集实际值
乱码不是靠猜的，先查清楚每层到底用了什么：
- 服务端默认：执行
SHOW VARIABLES LIKE 'character_set_server';，应为utf8mb4 - 数据库默认：执行
SHOW CREATE DATABASE db_name;，看CHARACTER SET是否为utf8mb4 - 表/列：执行
SHOW CREATE TABLE table_name;，确认DEFAULT CHARSET=utf8mb4且字段定义含CHARACTER SET utf8mb4 - 连接层：执行
STATUS;或SHOW VARIABLES LIKE 'character_set%';，重点看character_set_client、character_set_connection、character_set_results—— 这三个必须全为utf8mb4
连接时强制指定utf8mb4（应用侧最可靠手段）
即使服务端设了默认值，客户端发起连接时仍可能用旧协议协商出 latin1 或 utf8。必须显式声明：
- 命令行客户端：
mysql -u user -p --default-character-set=utf8mb4 db_name - PHP PDO：在 DSN 中加
;charset=utf8mb4，例如mysql:host=localhost;dbname=test;charset=utf8mb4 - Python pymysql：构造连接时传参
charset='utf8mb4' - Java JDBC URL：加
?characterEncoding=utf8mb4&serverTimezone=UTC - Node.js mysql2：配置项
charset: 'utf8mb4'
注意：utf8 是 MySQL 的别名，实际只支持 BMP 字符（最多 3 字节），utf8mb4 才真正支持 emoji 和生僻汉字（4 字节）。
修改已存在表的字符集（不能只改表，必须连字段一起）
执行 ALTER DATABASE db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; 只改数据库默认值，不影响已有表。要彻底生效，需两步：
- 改表默认字符集：
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 但若字段定义中显式写了
CHARACTER SET latin1，上面语句不会覆盖它 —— 必须单独改字段：ALTER TABLE table_name MODIFY column_name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 特别注意：
CONVERT TO会重建表，大数据量时锁表时间长；生产环境建议在低峰期操作，并提前备份
my.cnf 配置文件的坑（重启才生效，且优先级易混淆）
很多人在 [mysqld] 段写 character-set-server=utf8mb4 就以为万事大吉，但漏了关键点：
-
[client]和[mysql]段也必须加default-character-set=utf8mb4，否则命令行工具仍走默认latin1 -
collation-server必须与character-set-server匹配，推荐统一用utf8mb4_unicode_ci - 修改后必须重启 MySQL 服务，仅重载配置不生效
- 某些云数据库（如阿里云 RDS）不支持修改
my.cnf，只能通过控制台参数组调整，且部分参数不可变更
真正的难点不在设置本身，而在于四层字符集是否真正对齐 —— 尤其是连接层和字段层，最容易被忽略，也最常成为乱码根源。
