convert 和 cast 在 mysql 中不能直接实现“将 latin1 字段内容按 utf8 重新解释”这类字符集重解读；convert(expr using charset) 是真正的字符集编码转换（需原始字节合法），cast 不支持 using 语法，二者均不提供字节级强制重解释能力。
CONVERT 和 CAST 在 MySQL 里根本不能做字符集转换
直接说结论：CONVERT 和 CAST 在 MySQL 中不支持「把 latin1 字段内容按 utf8 解释」这类语义的字符集重解释。它们只能做类型转换（比如 CHAR → BINARY），或在有隐式转换规则时触发字符集转换——但这不是你手动控制编码解读的方式。
常见错误现象是：用 CONVERT(col USING utf8) 后查出来仍是乱码，或者报错 Illegal mix of collations。这是因为该语法实际做的是「将字符串从原字符集转为目标字符集编码」，前提是原内容本身编码正确。如果字段存的是 utf8 编码字节但被当成 latin1 打开，CONVERT(... USING utf8) 反而会二次错误转码。
-
CONVERT(str USING to_charset)是 MySQL 特有语法，本质调用iconv类逻辑，要求输入字节流本身符合源字符集定义 -
CAST(str AS CHAR CHARACTER SET utf8mb4)在 MySQL 8.0+ 支持，但同样依赖原始字节合法；若原始列定义是latin1而里面存了 utf8 字节，这个 CAST 不会“修复”解读方式 - 真正需要的是「以指定字符集重新解释二进制字节」，MySQL 没有直接函数，得靠
CONVERT(... USING binary)+CONVERT(... USING target)组合绕过
修复乱码数据必须先确认字节真实编码
这是最关键的一步，跳过就全错。比如一个 utf8mb4 列显示乱码，可能是：① 客户端连接字符集设错；② 原始插入时用了错误连接字符集；③ 字段本身定义错了。但如果你看到的是类似 “æž—è´µ” 这种，大概率是 utf8 编码字节被当 latin1 读取（即“双编码”问题）。
验证方法：用 HEX() 看原始字节，再人工比对。例如中文“林贵”正常 utf8 编码是 E69E97E8B4B5；如果字段值 HEX(col) 返回 C3A6C29EC297C3A8C2B4C2B5，说明它已被 latin1 错误解码过一次（每个 utf8 字节被拆成两个 latin1 字符）。
- 先执行
SELECT HEX(col), LENGTH(col), CHAR_LENGTH(col) FROM t WHERE id = 1—— 若LENGTH是CHAR_LENGTH的两倍，基本确认是 utf8 字节被当 latin1 存/读 - 不要直接 UPDATE，先用
SELECT CONVERT(CONVERT(col USING latin1) USING utf8mb4)测试是否还原出正确文字 - 测试成功后，才对整列执行
UPDATE t SET col = CONVERT(CONVERT(col USING latin1) USING utf8mb4)
ALTER TABLE 修改列字符集 ≠ 修正已有乱码
ALTER TABLE t MODIFY col VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 这类操作只是改元数据，不会重解释已存字节。如果原来存的是乱码字节，改完还是乱码，甚至可能因校对规则变化让排序更糟。
真正生效的路径只有两条：一是重建表（CREATE TABLE ... SELECT CONVERT(...)）；二是用上面提到的双重 CONVERT 更新内容。后者更常用，但要注意备份和事务安全。
- 执行前务必
mysqldump -t备份数据行，别只靠 SQL 语句备份 - 若列上有索引，更新后建议
ANALYZE TABLE t更新统计信息 - 修改后用
SHOW CREATE TABLE t确认列定义、连接字符集、表默认字符集三者一致
PostgreSQL 和 SQL Server 的处理逻辑完全不同
MySQL 的 CONVERT(... USING xxx) 是字符集转换；PostgreSQL 没有这个语法，要用 convert_from(bytea_col, 'LATIN1') 或 convert_to(text_col, 'UTF8')，且明确区分字节流和文本；SQL Server 的 CONVERT 主要用于类型转换，字符集由列定义和数据库排序规则决定，运行时无法动态 reinterpret 字节。
所以看到网上教程混用不同数据库的 CONVERT 示例，基本不可直接套用。跨数据库迁移时，最稳妥的是导出为十六进制字节，再按目标库规则重新导入。
- MySQL 导出原始字节：
SELECT HEX(col) FROM t - PostgreSQL 导入 UTF8 文本：
SELECT convert_from(decode('e69e97e8b4b5', 'hex'), 'UTF8') - SQL Server 没有内置 decode hex 函数，需用
CONVERT(VARBINARY, 'e69e97', 2)配合CAST组合
字符集问题从来不是单条 SQL 能一键解决的，核心永远是搞清那几个字节当初怎么进去、现在怎么出来。其他都是补救手段。
