嵌套查询“看起来相等却匹配不上”是因join或=比较时两边字段collation不兼容，mysql直接拒绝比较；须在子查询select列上用convert或collate显式对齐，且客户端连接层也必须统一为utf8mb4。
为什么嵌套查询关联字段会“看起来相等却匹配不上”
不是数据内容错了，是 MySQL 在执行 = 或 JOIN 时，发现两边字段的排序规则（collation）不兼容，直接拒绝比较。比如 t1.name 是 utf8mb4_0900_ai_ci，(SELECT name FROM t2) 返回的是 utf8mb4_unicode_ci，哪怕值都是 '张三'，也会报 Illegal mix of collations 错误。
CONVERT(expression USING charset) 必须作用在子查询的 SELECT 列上
常见错误是想“整个子查询转一次”，结果语法报错或无效。MySQL 不允许对子查询整体用 CONVERT，只能对它的输出列做转换。
- 错误写法：
CONVERT((SELECT name FROM t2), USING utf8mb4)→ 语法错误 - 正确写法：
(SELECT CONVERT(name USING utf8mb4) FROM t2) - 如果子查询多列，每列都要单独加
CONVERT，例如：(SELECT CONVERT(id USING utf8mb4), CONVERT(code USING utf8mb4) FROM t2) - 若用于
IN或=，只转子查询一侧不够——外层字面量也得对齐，比如写成_utf8mb4 'abc'
COLLATE 比 CONVERT 更轻量，且不改变存储编码
当两字段字符集相同（都是 utf8mb4），只是排序规则不同（如 utf8mb4_unicode_ci vs utf8mb4_0900_ai_ci），直接用 COLLATE 就够了，性能更好、无截断风险。
- JOIN 场景修复示例：
ON t1.code = t2.code COLLATE utf8mb4_unicode_ci - 子查询中对齐：
(SELECT code COLLATE utf8mb4_unicode_ci FROM t2) - 注意：不要只写
COLLATE utf8mb4_unicode_ci而不指定字段，它必须附着在具体字符串表达式后
真正容易被忽略的点：连接层字符集污染
就算表结构全改成 utf8mb4、所有字段都加了 COLLATE，只要客户端连接时 character_set_client 是 latin1 或 utf8（非 utf8mb4），MySQL 仍会在解析 SQL 前强行转码，导致 JOIN 条件里的中文参数从源头就失真。
- 查真实连接状态：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results - Java JDBC 必须带
?useUnicode=true&characterEncoding=utf8mb4（注意是&不是&） - Python pymysql 必须传
charset='utf8mb4'，写'utf8'会掉进 MySQL 的阉割版陷阱 -
SET NAMES utf8mb4只是临时补丁，长期应固化在连接串里
