CONVERT() 不能修复已损坏的字节，仅当存储字节正确但客户端误用字符集读取时才可临时纠正显示；若 HEX 结果为 3F3F3F 则数据已不可逆损坏，E4BDA0E5A5BD 等多字节序列才适用 CONVERT()。
CONVERT() 函数本身不会“修复”已损坏的字节
很多人误以为 CONVERT(name USING utf8mb4) 能把一堆问号（?）或乱码字符“变回”中文，其实不能。如果数据在存储时就已经被错误解码成 ?（比如 latin1 连接写入 utf8mb4 字段），那原始字节早已丢失，CONVERT() 只是在现有损坏数据上做无意义的二次转换，结果仍是乱码。
真正起作用的场景是：字段里存的是“对的字节”，但客户端用错字符集去读——例如字段实际存的是 utf8mb4 编码的 你好（字节序列 E4 BD A0 E5=A5=BD），而连接层用 latin1 解析，显示为 ä½ å¥½；这时 CONVERT(name USING utf8mb4) 才能把这串字节重新按 utf8mb4 解释，还原正确文字。
- 先查字段真实存储内容：
SELECT HEX(name) FROM users LIMIT 1;，如果结果是类似3F3F3F（即???的十六进制），说明数据已不可逆损坏 - 如果结果是
E4BDA0E5A5BD这类多字节序列，才适合用CONVERT()临时纠正显示 -
CONVERT()不改变表结构，只影响当前查询结果的编码解释方式
CONVERT() 引发排序规则冲突（ERROR 1267）
在 JOIN、WHERE 或视图中隐式调用 CONVERT() 时，MySQL 会自动为转换后的字段赋予目标字符集的默认 COLLATE。问题来了：MySQL 8.0 默认用 utf8mb4_0900_ai_ci，而老表可能建在 5.7 时期，用的是 utf8mb4_general_ci。两个 collation 不能直接比较，就会报 ERROR 1267 (HY000): Illegal mix of collations。
- 执行
SHOW CREATE VIEW your_view_name\G，看 WHERE 条件里是否出现convert(`col` using utf8mb4) - 显式指定 collation 可绕过冲突：
CONVERT(name USING utf8mb4) COLLATE utf8mb4_unicode_ci - 更稳妥的做法是统一表字段的 collation：
ALTER TABLE t1 MODIFY name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
CONVERT() 性能开销被低估
每次查询都用 CONVERT()，相当于对每一行做一次字符集重解释，无法走索引（即使原字段有索引，转换后也失效），在大表上会明显拖慢响应速度。
- 测试对比：
SELECT id, name FROM users WHERE name = '张三';vsSELECT id, CONVERT(name USING utf8mb4) AS name FROM users WHERE CONVERT(name USING utf8mb4) = '张三';，后者执行计划里type很可能变成ALL - 如果只是为解决显示问题，优先改连接层：
SET NAMES utf8mb4;或应用配置里加characterEncoding=utf8mb4 - 长期依赖
CONVERT()是在掩盖字符集配置缺陷，不是解决方案
系统表乱码时别乱用 CONVERT()
像 mysql.user 这类系统表出现中文用户名乱码，不是靠 CONVERT() 查询就能解决的。因为元数据本身（如用户名、权限注释）是以服务器初始化时的字符集写入的，如果当时是 latin1，现在用 utf8mb4 连接去查，看到的就是错位解析结果。
- 查系统表字符集：
SHOW CREATE TABLE mysql.user;，看CHARACTER SET是不是utf8mb4 - 直接
ALTER TABLE mysql.user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;有风险，MySQL 官方不推荐直接修改系统表结构 - 安全做法是：停库 → 备份
mysql库 → 用mysqldump --default-character-set=utf8mb4导出 → 清空目标库 → 修改 my.cnf 的character_set_server=utf8mb4→ 重启 → 导入
CONVERT() 就想一劳永逸，只会让问题更隐蔽、更难排查。 
