mysql日志乱码根本原因是字符集不一致，需逐层统一为 utf8mb4：服务端、连接层、表结构及终端显示环境均须匹配，并验证各层配置与 工具 编码。
MySQL 日志乱码，根本原因几乎都是字符集不一致导致的，尤其是客户端、连接层、服务端、表结构、甚至终端显示环境之间 编码 不统一。解决的关键是逐层确认并统一为 utf8mb4（推荐）或至少 utf8，并确保全程无断点。
检查 MySQL 服务端默认字符集
登录 MySQL 后执行：
SHOW VARIABLES LIKE ‘character_set%’;
SHOW VARIABLES LIKE ‘collation%’;
重点关注：
• character_set_server：服务端默认字符集（应为 utf8mb4）
• collation_server：对应排序规则（如 utf8mb4_unicode_ci）
• init_connect：若设置了 SET NAMES，需确认其值是否匹配
若不匹配，修改 my.cnf（linux）或 my.ini（windows）的 [mysqld] 段：
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
重启 MySQL 生效。
确保客户端连接使用正确字符集
即使服务端设对了，客户端连接时未声明编码，仍会走默认（可能为 latin1）。有三种常用方式保障：
- 连接时显式指定：
mysql -u user -p --default-character-set=utf8mb4 - 在 配置文件 [client] 段统一设置（影响所有本地客户端）：
[client]
default-character-set = utf8mb4 - 连接后立即执行：
SET NAMES utf8mb4;（等价于 SET character_set_client=utf8mb4; SET character_set_results=utf8mb4; SET character_set_connection=utf8mb4;）
检查表与列的实际字符集
服务端和连接都对了，但旧表建表时用了 latin1 或 utf8（非 utf8mb4），存入的中文或 emoji 仍可能出问题，查法：
SHOW CREATE table your_tableG
看 CREATE TABLE 语句中各字段的 CHARACTER SET 和 COLLATE。常见错误包括：
- 字段定义为
VARCHAR(255) CHARACTER SET latin1 - 虽写 utf8，但 MySQL 5.7 及以前的 utf8 实际是 utf8mb3（不支持 4 字节 字符）
修复方法（以表 t1 的 name 字段为例）：
ALTER TABLE t1 MODIFY name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
建议整库批量转换前先备份，并确认应用层兼容 utf8mb4。
别忽略终端 / 日志查看 工具 的编码
MySQL 错误日志（Error log）、慢查询日志（slow log）、general log 等本身是纯文本文件。如果用 less、vim、notepad++ 或某些 ide 打开时显示乱码，大概率是查看工具用了错误编码解析。
