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）。有三种常用方式保障：
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
- 连接时显式指定：
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_table\G看 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 打开时显示乱码，大概率是查看工具用了错误编码解析。
- Linux 终端：确认 locale 是 UTF-8（
locale | grep UTF），避免 LANG=C - Windows 记事本：另存为时选“UTF-8”而非“ANSI”；推荐用 VS Code、Notepad++ 并手动设编码为 UTF-8
- 日志内容含中文但显示为问号或方块 → 查看工具解码错误
日志内容显示为类似 “\xE4\xBD\xA0\xE5\xA5\xBD” → 实际是十六进制转义，说明日志被以二进制或 hex 方式输出，不是真正乱码，而是格式问题
