SQL乱码源于“输入→传输→存储→读取→显示”任一环节字符集不一致，核心是统一为utf8mb4：查会话与服务器五项变量、表字段实际字符集、SQL文件编码与导入参数、应用层连接配置，逐层对齐即可修复。
SQL乱码不是随机发生的，而是字符在“输入→传输→存储→读取→显示”任一环节编码不一致导致的链式错位。排查核心是确认每个环节用的是什么字符集，并让它们对齐——尤其是 utf8mb4 这个真正支持中文和 emoji 的标准。
查当前会话与服务器字符集配置
登录 MySQL 后第一时间执行：
SHOW VARIABLES LIKE 'character\_set\_%';
重点关注这五项是否统一为 utf8mb4：
- character_set_client：客户端发来的原始编码
- character_set_connection：SQL 解析和转换时用的中间编码
- character_set_results：返回给客户端的结果编码
- character_set_database：当前数据库默认字符集
- character_set_server：MySQL 实例级默认字符集
只要其中任意一项是 latin1、gbk 或 utf8（非 utf8mb4），就埋下了乱码隐患。
看表和字段实际使用的字符集
即使数据库设了 utf8mb4，单个表或字段仍可能沿用旧配置。检查方式：
SHOW CREATE TABLE 表名;
观察 DEFAULT CHARSET 和各 VARCHAR/TEXT 字段的 COLLATE。常见问题包括：
- 表是 utf8，但字段没显式声明，继承了过时的 utf8（三字节限制）
- 字段用了 utf8mb4，但 collation 是 utf8mb4_general_ci（已弃用），建议换 utf8mb4_unicode_ci 或 utf8mb4_0900_as_cs
- 字段类型是 CHAR/VARCHAR 却没加 N 前缀（仅 SQL Server 需要，MySQL 不依赖此）
验 SQL 文件与导入方式是否匹配
从 .sql 文件导入时，乱码高发于“文件本身编码 ≠ 导入时声明的编码”。操作要点：
- 用 file -i 文件名.sql 或编辑器确认文件真实编码（应为 UTF-8 无 BOM）
- 命令行导入必须带参数：mysql -u 用户 -p --default-character-set=utf8mb4 数据库名
- 若先登录再 source，务必在 use 数据库后立刻执行：SET NAMES utf8mb4;
- Navicat/HeidiSQL 等工具需在连接属性中手动指定“字符集”为 utf8mb4，不能只靠自动检测
盯应用层连接参数是否生效
程序连库出乱码，往往卡在驱动没传对参数。典型配置示例：
- JDBC：useUnicode=true&characterEncoding=UTF-8&connectionCollation=utf8mb4_unicode_ci
- Python pymysql：charset='utf8mb4'（注意是 utf8mb4，不是 utf8）
- PHP PDO：charset=utf8mb4 加在 DSN 里，如 mysql:host=localhost;dbname=test;charset=utf8mb4
光改数据库配置没用——如果应用每次建连都用默认 latin1，那所有数据进来就已损坏。
基本上就这些。乱码看着吓人，其实是一条可追踪、可验证、可逐层修复的路径。关键不在“试”，而在“查”；不靠重启，而靠对齐。
