本质是collation冲突而非数据错误，需同步修复字段定义、子查询输出和连接层三者；嵌套查询中左右collation不兼容（如utf8mb4_unicode_ci与utf8mb4_0900_as_cs）时，mysql在=、in、join等操作中直接报错1267。
字符集不一致导致的嵌套查询报错，本质是 collation 冲突，不是数据错了，而是 MySQL 拒绝在不兼容排序规则间做比较。 直接改表或加 CONVERT 都可能白忙——关键得同步修复字段定义、子查询输出、连接层三者。
为什么嵌套查询会报 Illegal mix of collations
典型错误信息：Illegal mix of collations (utf8mb4_unicode_ci,IMPLICIT) and (utf8mb4_0900_as_cs,IMPLICIT)。这不是语法错，是 MySQL 在执行 =、IN 或 JOIN 时发现左右两边字段的 COLLATE 不兼容，直接中止。
- t1.name 是
utf8mb4_0900_as_cs，子查询(SELECT name FROM t2)返回的是utf8mb4_unicode_ci，哪怕值都是 '?'，也会报错 - 即使两个字段都是
utf8mb4字符集，只要COLLATE不同（比如_unicode_civs_0900_as_cs），就可能触发 - 错误常出现在子查询用于
WHERE ... IN、JOIN ON、标量子查询返回值参与比较等场景
子查询 SELECT 列必须显式对齐 collation
不能对整个子查询用 CONVERT，MySQL 不支持这种写法；只能作用于子查询的每一列输出。
- 错误写法：
CONVERT((SELECT name FROM t2), USING utf8mb4)→ 语法错误 - 正确写法：
(SELECT name COLLATE utf8mb4_0900_as_cs FROM t2)或(SELECT CONVERT(name USING utf8mb4) FROM t2) - 多列时每列都得单独处理：
(SELECT id, code COLLATE utf8mb4_0900_as_cs, remark COLLATE utf8mb4_0900_as_cs FROM t2) - 如果只是排序规则不同、字符集相同，优先用
COLLATE，比CONVERT更轻量，无截断风险
连接层字符集必须统一为 utf8mb4
就算表和子查询全对齐了，只要客户端连进来时 character_set_client 是 latin1 或 utf8（即 utf8mb3），SQL 解析阶段就会把中文或 Emoji 强行转码，导致条件失真。
- 查真实状态：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results - JDBC 连接串必须含：
?useUnicode=true&characterEncoding=utf8mb4（注意是&，不是&） - PyMySQL 初始化必须传：
charset='utf8mb4'；写成'utf8'就掉进 MySQL 的阉割版陷阱 -
SET NAMES utf8mb4只是临时补丁，长期应固化在连接配置里
ALTER TABLE 改字段 collation 容易漏的关键点
只改 CHARACTER SET 或只改 COLLATE 都等于白干，必须两者同时指定，且要和关联表字段完全对齐。
- 错误写法：
ALTER TABLE t2 CONVERT TO CHARACTER SET utf8mb4→ 保留原COLLATE，可能还是utf8mb4_general_ci - 正确写法：
ALTER TABLE t2 MODIFY name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs - 批量改多个字段：分步写
MODIFY a、MODIFY b，避免锁表太久 - 改完立刻验证：
SHOW CREATE TABLE t2确认字段定义，再跑EXPLAIN看是否走索引
真正容易被忽略的是：连接层污染比表结构问题更隐蔽，它让所有上层修复都失效。确认 @@collation_connection 和字段 COLLATE 对齐后，再检查子查询输出是否被隐式降级——尤其当外层有 CONCAT()、GROUP BY 或 ORDER BY 时，MySQL 会按会话默认 collation 重解释结果。
