CONVERT函数在嵌套查询中报错的根本原因是子查询与外层查询字符集不兼容导致隐式转换失败；需用CONVERT(expression USING charset)显式转换子查询字段，注意utf8mb4≠utf8、latin1≠utf8，且expression不能是子查询本身。
CONVERT函数在嵌套查询中为什么突然报错
根本原因是子查询返回的字段字符集（如 utf8mb4）与外层查询期望的字符集（如 latin1 或隐式推导出的 utf8）不兼容，MySQL 在执行 IN、=、JOIN 等操作时会尝试隐式转换，失败就抛出类似 Illegal mix of collations 的错误。
常见触发场景：跨库关联（不同库默认字符集不同）、视图嵌套、或从 INFORMATION_SCHEMA 等系统表查出字段后直接用于业务表条件匹配。
CONVERT 本身不是万能解药——它只改字符集不改排序规则（collation），若目标 collation 不支持源内容（比如 CONVERT(... USING latin1) 处理含 emoji 的字符串），仍会截断或报错。
CONVERT(... USING ...) 的正确写法和参数陷阱
语法必须是 CONVERT(expression USING charset)，不能写成 CONVERT(charset, expression)（那是旧版 SQL Server 风格，MySQL 不认）。
关键点：
-
expression必须是列名、字面量或简单表达式，不能是子查询本身（比如CONVERT((SELECT name FROM t2), USING utf8mb4)会语法错误） - 字符集名要拼写准确：
utf8mb4≠utf8；latin1≠utf8 - 如果嵌套在
IN子句里，需对子查询的 SELECT 列显式 CONVERT，而不是对外层字段转
示例（修复 IN 报错）：
SELECT * FROM users WHERE username IN ( SELECT CONVERT(username USING utf8mb4) FROM legacy_users WHERE status = 'active' );
比 CONVERT 更稳的替代方案：COLLATE 和 CAST
当只需临时对齐排序行为，COLLATE 比 CONVERT 更轻量，且不改变数据存储编码：
- 用
SELECT username COLLATE utf8mb4_unicode_ci FROM legacy_users可避免隐式转换冲突 -
CAST在部分场景更明确：CAST(username AS CHAR CHARACTER SET utf8mb4)，语义上强调类型+字符集双重转换 - 若子查询来自
INFORMATION_SCHEMA，优先用COLLATE，因为其字段常为utf8，而业务表是utf8mb4，仅对齐 collation 就够用
注意：CAST(... AS CHAR) 默认使用连接字符集，仍可能出问题，务必显式加 CHARACTER SET。
真正根治：别让问题进到嵌套查询里
CONVERT 是补救手段，长期看应从源头控制字符集一致性：
- 新建表时统一用
CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci - 连接层（如 JDBC URL）加上
characterEncoding=utf8mb4，避免客户端传入乱码 - 检查
SHOW VARIABLES LIKE 'character_set%'，确保character_set_client、connection、results三者一致 - 对已存在的混合字符集表，用
ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci批量修正（注意备份）
嵌套查询一旦涉及多字符集混用，哪怕加了 CONVERT，也可能在排序、索引使用、甚至 GROUP BY 时悄悄失效——这些细节往往比报错更难排查。
