子查询报错“Illegal mix of collations”是因主查与子查字段字符集或排序规则不一致；需在子查询SELECT列上用CONVERT(... USING utf8mb4)或CAST显式转换，且UNION各分支、GROUP BY/ORDER BY字段及IN左值均须统一collation。
为什么子查询报错“Illegal mix of collations”
MySQL 在执行子查询时，如果主查询字段和子查询返回字段的字符集或排序规则（collation）不一致，就会抛出 Illegal mix of collations 错误。这不是语法问题，而是 MySQL 严格校验字符串比较/连接时的编码兼容性——比如主表用 utf8mb4_unicode_ci，子查询结果却是 latin1_swedish_ci，哪怕内容都是 ASCII 字符，也会直接拒绝执行。
CONVERT 函数怎么用才真正生效
CONVERT 必须作用在子查询的**最终输出列**上，而不是包裹整个子查询。常见错误是写成 CONVERT((SELECT ...), CHAR CHARACTER SET utf8mb4)，这在 MySQL 中语法不合法；正确方式是在子查询内部对 SELECT 的列显式转换。
- 对单列子查询：写成
(SELECT CONVERT(name USING utf8mb4) FROM users WHERE id = 1) - 对多列或需要指定 collation 的场景：用
CONVERT(... USING utf8mb4) COLLATE utf8mb4_unicode_ci - 如果子查询带
GROUP BY或ORDER BY，这些子句中的字段也需统一转换，否则仍可能触发 collation 冲突
比 CONVERT 更稳妥的替代方案
当子查询来自不同数据库、视图或临时表时，CONVERT 容易漏掉隐式字段（如函数生成列、别名列）。更可靠的做法是提前声明结果集的字符集：
- 在子查询外层加
CAST(... AS CHAR CHARACTER SET utf8mb4)，它比CONVERT更明确支持类型+字符集组合 - 若子查询涉及
UNION，所有分支的对应列必须用相同CONVERT或CAST，否则第一个分支决定整体 collation，后续分支不匹配就报错 - 检查
SHOW VARIABLES LIKE 'character_set%'和SHOW VARIABLES LIKE 'collation%'，确保客户端、连接、数据库默认值一致，避免源头污染
容易被忽略的隐式转换陷阱
某些操作会悄悄触发 collation 升级，导致原本没问题的子查询突然失败。例如：
-
CONCAT(col1, (SELECT name FROM t2))：即使col1是 utf8mb4，子查询结果若为 latin1，CONCAT会按“最宽泛 collation”合并，可能选错规则 - 使用
IN子查询时，MySQL 会把右值列表和子查询结果做 collation 对齐，此时只转换子查询不够，左边的字面量字符串也要加_utf8mb4 'xxx'前缀 - 存储过程里用
DECLARE v_name VARCHAR(100) DEFAULT ''，这个空字符串默认用连接字符集，和子查询结果拼接时也可能冲突
字符集问题从来不是孤立的——它总藏在连接初始化、表定义、函数返回值、甚至 SQL 模式开关的缝隙里。修一个 CONVERT 很快，但漏掉某处隐式推导，下一次报错就在你改完上线五分钟之后。
