当你在 MySQL 中遇到乱码时，往往不是单一原因造成的。MySQL 字符集乱码问题涉及客户端、连接、服务器、数据库、表、列等多个层级，任何一个环节设置不一致都可能导致数据写入或读取时出现乱码。本文将从现象出发，按层级逐一排查，并给出修复方案。
1. 乱码现象：先判断是写入还是读取问题
乱码通常分为两类：一是写入时就已损坏，二是写入正常但读取显示异常。区分方法很简单：在 MySQL 命令行客户端中直接查询该数据，如果显示正常，说明数据本身没问题，问题出在应用读取环节；如果命令行也显示乱码，则可能是写入环节或存储环节出了问题。
2. 检查客户端与连接字符集
客户端字符集是乱码最常见的原因。MySQL 连接建立时，会协商字符集，如果客户端设置的字符集与服务器端不一致，就会导致乱码。例如，在 Java 应用中，JDBC URL 未指定 characterEncoding，或指定为 UTF-8 但数据库实际使用 latin1，都会导致乱码。
排查步骤：
- 执行
SHOW VARIABLES LIKE 'character_set_client';查看当前连接字符集。 - 执行
SHOW VARIABLES LIKE 'character_set_connection';查看连接字符集。 - 执行
SHOW VARIABLES LIKE 'character_set_results';查看结果集字符集。
如果三者不一致，可以通过 SET NAMES utf8mb4; 快速统一，但更推荐在连接配置中明确指定。例如，JDBC 中设置 characterEncoding=utf8，Python 中设置 charset='utf8mb4'。
3. 检查数据库与表字符集
数据库和表的字符集决定了数据存储的编码。如果表是 latin1，而客户端写入的是 UTF-8，数据就会按 latin1 存储，导致乱码。查看数据库字符集：SHOW CREATE DATABASE dbname;，查看表字符集：SHOW CREATE TABLE tablename;。
修复方法：使用 ALTER DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 修改数据库字符集，使用 ALTER TABLE tablename CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 转换表字符集。但注意，CONVERT 会改变列的数据类型，如果列是 varchar，会改变长度计算方式，可能导致超长，需提前评估。
4. 排查服务器端字符集设置
服务器全局字符集设置会影响新建的数据库和表的默认字符集。查看服务器字符集：SHOW VARIABLES LIKE 'character_set_server';。如果服务器默认是 latin1，新建的库表就会默认 latin1，容易埋下乱码隐患。建议在配置文件 my.cnf 中设置：
[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci
修改后需要重启 MySQL 服务生效。
5. 数据已损坏的修复策略
如果数据写入时已经乱码，简单修改字符集可能无法恢复。例如，UTF-8 字节被当作 latin1 存储，再转回 UTF-8 时可能已丢失信息。此时需要根据原始编码进行“转码”操作，但前提是数据未发生不可逆损坏。
一种常见场景：若数据原本是 UTF-8，但被误写成 latin1，可以通过 ALTER TABLE ... MODIFY col VARBINARY; 先转为二进制，再转回 UTF-8。更安全的做法是先用 mysqldump 导出数据，在导出时指定正确的字符集，再导入到新库中。例如：
mysqldump -u root -p --default-character-set=utf8mb4 dbname > dump.sql
mysql -u root -p --default-character-set=utf8mb4 dbname < dump.sql
6. 常见误区与失败条件
误区一：只修改表字符集，不修改连接字符集。即使表是 utf8mb4，如果连接是 latin1，写入时 MySQL 会尝试转换，可能导致乱码。
误区二：使用 utf8 而不是 utf8mb4。MySQL 的 utf8 实际上是 utf8mb3，无法存储 emoji 等四字节字符，会导致插入失败或乱码。建议统一使用 utf8mb4。
误区三：直接对乱码数据执行 CONVERT。如果数据已损坏，CONVERT 可能产生错误结果，应先备份，再尝试。
失败条件：如果数据在写入时经过了不可逆的转换，如从 UTF-8 转为 GBK 再转回，原始字节已丢失，无法恢复。
7. 验证与监控
修复后，应验证数据是否正常显示。同时，建议在应用层增加日志记录，记录字符集设置和异常情况，便于后续排查。参考 OWASP 日志安全速查表，日志应包含足够的上下文信息，如连接 ID、SQL 语句等。另外，OpenTelemetry 日志规范建议将日志与追踪关联，便于定位问题。Python 的 logging 模块提供了灵活的日志配置，可以在应用中使用。
参考资料
延伸阅读