MySQL 的 CONVERT() 函数不支持字符集转换，CONVERT(str USING utf8mb4) 是字符串转换操作符而非函数调用；真正字符集转换需修改列定义、连接层设置或谨慎使用双重 CONVERT 修复乱码。

CONVERT 函数在 MySQL 中根本不能转换字符集

MySQL 的 CONVERT() 函数只支持类型转换（比如 CONVERT('123', SIGNED)），不接受字符集作为目标参数。你看到的 CONVERT(str USING utf8mb4) 语法，其实是 MySQL 特有的 **字符串转换操作符**，不是函数调用——括号里没逗号、USING 是关键字，不是参数。

• 写成 CONVERT(str USING utf8mb4) ✅ 正确（这是表达式，不是函数）
• 写成 CONVERT(str, utf8mb4) ❌ 报错：ERROR 1064 (42000)
• 写成 CONVERT(str USING 'utf8mb4') ❌ 单引号会报 ERROR 1054 (42S22): Unknown column 'utf8mb4'

真正生效的字符集转换必须作用于列定义或连接层

运行时用 CONVERT(str USING utf8mb4) 只改变该表达式的临时编码，不影响存储、不修复乱码根源。真要转存，得改表结构或导入流程。

• 修改列字符集：ALTER TABLE t MODIFY c VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• 批量更新已有乱码数据（慎用）：UPDATE t SET c = CONVERT(CONVERT(c USING latin1) USING utf8mb4); —— 前提是原始字节被错误当成了 latin1 解码
• 连接时指定编码比单条语句转换更可靠：SET NAMES utf8mb4; 或在客户端连接串中加 ?charset=utf8mb4

CONVERT(… USING …) 容易触发隐式截断和乱码回退

如果源字节序列在目标字符集里无法表示（比如 GBK 中的某个字在 UTF8MB4 里没有对应码位），MySQL 默认不会报错，而是替换成 ? 或静默丢弃字节，导致数据损坏不可逆。

• 检查是否发生替换：SELECT c, HEX(c), CONVERT(c USING utf8mb4) FROM t WHERE c REGEXP '[^[:ascii:]]' LIMIT 10; 对比 HEX 值变化
• 启用严格模式可捕获问题：SET sql_mode = 'STRICT_TRANS_TABLES';，但仅对 DML 生效，对 SELECT 中的 CONVERT 无效
• UTF8MB4 到 GBK 转换风险更高：一个 emoji 占 4 字节，GBK 根本存不下，直接变 ??

别依赖 CONVERT 修复历史乱码，先确认原始编码再操作

把“锟斤拷”“”这类乱码用 CONVERT 盲转，大概率越转越糟。核心是还原当初存入时被误判的源编码（比如实际是 UTF8 但被当作了 latin1 写入）。

• 查原始字节：SELECT HEX(c), LENGTH(c), CHAR_LENGTH(c) FROM t WHERE c LIKE '%%' LIMIT 1; —— 如果 HEX 长度是 CHAR_LENGTH 的两倍，大概率是 UTF8 当 latin1 存了
• 验证猜测：SELECT CONVERT(CONVERT(UNHEX('e4b8ad') USING latin1) USING utf8mb4); 看是否输出 “中”
• 生产环境务必先备份再执行 UPDATE，且避免在高并发写入时跑全表转换

字符集转换不是格式化字符串，它动的是字节解释逻辑。一个没对上的 USING，就可能让整列中文变成问号山。