怎样修复MySQL 8.0中因字符集不一致导致的字符串函数乱码？-mysql教程-PHP中文网

数据本身未损坏，乱码源于substr等函数在latin1连接字符集下错误解析utf-8字节；三者character_set_client/connection/results必须全为utf8mb4，且函数中所有using和cast均须显式指定utf8mb4。

怎样修复mysql 8.0中因字符集不一致导致的字符串函数乱码？

SELECT HEX() 显示合法 UTF-8 字节但函数结果乱码

这说明数据本身没坏，是 SUBSTR、REPLACE、CONCAT 等函数在执行时用了错误的字符集上下文。MySQL 会按 character_set_connection 解析字符串字面量，并按该字符集做内部运算——如果它是 latin1，哪怕字段存的是 utf8mb4，REPLACE('你好', '好', '棒') 也会被当成 4 个 latin1 字节处理，切分错位、替换失效。

验证方式：运行 SELECT @@character_set_client, @@character_set_connection, @@character_set_results; ——三者必须全为 utf8mb4。常见陷阱是只改了 character_set_server，却没碰连接层。

临时修复：在执行含中文的字符串函数前，先运行 SET NAMES utf8mb4;
脚本执行时，第一行必须是 SET NAMES utf8mb4;，不能依赖配置文件自动生效
避免在存储过程中硬写中文字符串（如 SET @msg = '成功';），除非确认创建过程前已设好连接字符集

函数返回值被截断或显示为问号

CONVERT、CAST 或隐式转换触发乱码，往往是因为目标字符集不兼容。例如字段定义为 VARCHAR(255) CHARACTER SET utf8mb4，但函数里写 CONVERT(col USING utf8)，就会把 4 字节 emoji 当作非法序列丢弃，变成 ?。

根本原因：MySQL 的 utf8 是别名，实际为 utf8mb3，不支持 emoji；而 utf8mb4 才是完整 UTF-8。任何显式或隐式使用 utf8 的转换都可能出问题。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

检查函数中所有 USING 子句，替换成 utf8mb4，例如：CONVERT(col USING utf8mb4)
避免用 CAST(col AS CHAR)，它默认走 character_set_connection；应写成 CAST(col AS CHAR CHARACTER SET utf8mb4)
ORM 或应用层调用函数时，确保连接参数带 charset=utf8mb4，否则驱动可能绕过服务端设置

ORDER BY / GROUP BY 中文排序异常或结果不稳定

这不是乱码，但常被误认为是字符集问题——实际是排序规则（collation）不匹配导致的。比如字段用 utf8mb4_0900_as_cs，但 ORDER BY name 却按 utf8mb4_unicode_ci 比较，大小写敏感性、重音处理逻辑不同，结果顺序就飘。

更隐蔽的问题：主从库 collation 不一致时，从库 GROUP BY 可能合并错误的行，因为比较逻辑变了，但错误不报错，只悄悄出错。

查字段真实 collation：SHOW FULL COLUMNS FROM t1 LIKE 'name';，确认 Collation 列是 utf8mb4_0900_as_cs 或 utf8mb4_unicode_ci，且主从一致
函数内强制指定 collation：ORDER BY name COLLATE utf8mb4_0900_as_cs
避免在函数里混用不同 collation 的字段，例如 CONCAT(a, b) 中 a 和 b collation 不同，结果会退化为 utf8mb4_bin，排序完全失效

mysqldump 导出后函数逻辑失效

导出的 SQL 文件里，如果建表语句没带 CHARACTER SET utf8mb4，或者函数体里的中文字符串被 mysqldump 用 latin1 读出来再写进去，那恢复后 CREATE FUNCTION f() RETURNS VARCHAR(100) BEGIN RETURN '测试'; END 里的 '测试' 已经是损坏字节，函数一执行就返回乱码。

关键点：mysqldump 默认按 character_set_client 读数据，不是按表定义读——所以即使表是 utf8mb4，若 dump 时连接是 latin1，函数体就废了。