在 MySQL 中，字符集问题常导致乱码、数据存储异常或查询不准确。排查这类问题需从连接、表结构、字段定义到服务器配置逐层检查。关键是理解字符集在不同层级的生效逻辑，并通过标准化设置避免冲突。
确认当前字符集配置
先查看 MySQL 服务器和会话的默认字符集：
SHOW VARIABLES LIKE 'character_set%'; SHOW VARIABLES LIKE 'collation%';
重点关注以下变量：
character_set_server：服务器默认字符集 character_set_database：当前数据库的字符集 character_set_client：客户端发送数据的字符集 character_set_connection：连接层转换用的字符集 character_set_results：返回结果使用的字符集若这些值不一致，尤其是 client、connection、results 与表实际字符集不符，就容易出问题。
检查数据库与表的字符集
查看具体数据库和表的字符集定义：
-- 查看数据库字符集 SHOW CREATE DATABASE db_name; <p>-- 查看表结构和字符集 SHOW CREATE TABLE table_name;</p>
确保表和字段的字符集明确指定且统一，例如：
推荐使用 utf8mb4 而非 utf8（MySQL 的 utf8 实为 utf8mb3，不支持四字节字符） 排序规则建议用 utf8mb4_unicode_ci 或 utf8mb4_general_ci如果发现字段仍为 latin1 或 utf8，应考虑修改：
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
验证客户端连接字符集
即使服务器配置正确，客户端连接时未正确声明字符集也会导致乱码。例如：
应用程序连接时未执行SET NAMES utf8mb4JDBC 连接字符串缺少
characterEncoding=utf8参数 PHP PDO 未设置
PDO::MYSQL_ATTR_INIT_COMMAND初始化命令
建议在建立连接后立即设置字符集：
SET NAMES utf8mb4;
这相当于同时设置 client、connection、results 为 utf8mb4。
模拟与复现乱码场景
若已有乱码数据，可通过以下方式判断来源：
对比原始输入与数据库存储内容，观察是否出现问号（?）、 或双编码字符（如“ü”代表误转的“ü”） 使用 HEX() 函数查看字段的十六进制值，分析编码路径 例如：SELECT HEX(column), column FROM table LIMIT 1;
若 HEX 值显示为 C2 A1 等 UTF-8 编码但客户端以 latin1 解读，就会显示为 ¡。这类线索能帮助定位转换断点。
统一并固化字符集设置
为避免后续问题，应在配置文件中固定字符集：
[mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci <p>[client] default-character-set = utf8mb4</p>
重启服务后，新建库表将自动使用 utf8mb4。同时在应用层确保每次连接都明确设置字符集。
基本上就这些。关键不是一次修复，而是确保各环节字符集一致，从源头杜绝错乱转换。
