mysql乱码问题可通过hex()函数辅助排查。当怀疑字段乱码时，先用select hex(column_name) from table_name where id = xxx查看十六进制值，如“中”在utf-8下应为e4b8ad；若显示其他组合如c3a4 c2b8 c2ad，则存在编码转换错误。接着检查连接字符集设置，通过show variables like ‘character_set%’确认各变量是否为utf8mb4，必要时用set names ‘utf8mb4’调整。再对比前后端编码一致性，如php中需调用mysqli_set_charset($conn, “utf8mb4”)，Java jdbc连接串需含useunicode=true&characterencoding=utf-8。最后可用select convert(cast(unhex(hex(column_name)) as binary) using utf8mb4)修复已乱码数据。关键在于明确各环节编码设定并结合hex()看清原始字节内容。
MySQL乱码问题在日常开发中经常出现，特别是在处理中文数据时。使用 HEX() 函数可以帮助我们快速判断数据在传输或存储过程中是否发生了编码转换的问题。下面直接说重点：HEX() 可以将字符串转换为十六进制表示，从而帮助我们看清原始字节内容，定位乱码源头。
查看字段的十六进制值
当你怀疑某张表中的某个字段出现了乱码，可以先使用 HEX() 函数查看该字段的实际字节表示：
SELECT HEX(column_name) FROM table_name WHERE id = xxx;
这样可以看到该字段内容在数据库中实际是以什么编码方式存储的。比如，中文字符“中”如果正常用 UTF-8 编码，对应的十六进制是 E4B8AD。如果你看到的是其他组合，比如 C3A4 C2B8 C2AD（这是 UTF-8 被误当 Latin1 解析的结果），那说明可能在某个环节出现了编码转换错误。
检查连接和字符集设置
很多乱码问题不是出在数据本身，而是出在连接、传输或客户端显示上。你可以通过以下命令检查当前连接的字符集配置：
SHOW VARIABLES LIKE 'character_set%';
常见应该设置为 utf8mb4 的变量包括：
- character_set_client
- character_set_connection
- character_set_database
- character_set_results
- character_set_server
如果你发现这些设置中有不是 utf8mb4 的，可以在 MySQL 配置文件中统一修改，或者在连接时手动指定：
SET NAMES 'utf8mb4';
这一步很关键，因为即使你存的是正确的 UTF-8 字符，但客户端用别的编码去解析，也会显示乱码。
对比前后端编码一致性
有时候，乱码问题出现在应用层与数据库之间。例如，前端页面用了 UTF-8，而后端代码连接数据库时没有正确声明编码，就可能导致插入或查询时出现异常。
举个例子，在 PHP 中连接数据库时要加上：
mysqli_set_charset($conn, "utf8mb4");
在 Java 的 JDBC 连接串里也要带上编码参数：
jdbc:mysql://localhost:3306/db?useUnicode=true&characterEncoding=UTF-8&connectionCollation=utf8mb4_unicode_ci
这类设置如果不统一，即使你在数据库里看到 HEX() 是对的，也可能在界面上显示乱码。
使用HEX辅助修复乱码数据
对于已经乱码的数据，也可以尝试用 HEX() 辅助修复。比如某些情况下，数据被错误地当作 Latin1 存储了 UTF-8 字符，可以通过如下方式还原：
SELECT CONVERT(CAST(UNHEX(HEX(column_name)) AS BINARY) USING utf8mb4) AS fixed_value FROM table_name WHERE id = xxx;
这个表达式的意思是：先把字段转成十六进制，再还原成二进制，最后按 UTF-8 解码。如果结果正常了，说明确实是编码转换的问题，可以用类似的语句批量更新数据。
基本上就这些。排查 MySQL 乱码不复杂，但容易忽略细节。关键是搞清楚每个环节的编码设定，再结合 HEX() 看清数据本质。
