COLLATE不能单独加在JOIN条件里修复乱码匹配，必须配合CONVERT()或ALTER TABLE才有效；否则易报Illegal mix of collations且索引失效。
直接结论：COLLATE 不能单独加在 JOIN 条件里“修”乱码匹配，必须配合 CONVERT() 或 ALTER TABLE 才有效；否则大概率报 Illegal mix of collations，且索引失效。
为什么 ON t1.name COLLATE utf8mb4_unicode_ci = t2.name 会失败
MySQL 在解析 ON 子句前，会先做隐式校对规则推导。只要 t1.name 和 t2.name 的原始 COLLATION 不同（比如一个是 utf8mb4_bin，另一个是 utf8mb4_unicode_ci），即使你显式写了 COLLATE，也可能因表达式优先级或类型兼容性检查失败而中断。这不是语法错误，而是执行计划生成阶段就卡住了。
常见表现：
- 查询直接报错：
Illegal mix of collations - 看似执行成功，但 EXPLAIN 显示
type: ALL，索引没用上 - 结果偶尔对、偶尔空——取决于优化器是否“碰巧”绕过校验
真正能用的 COLLATE 写法只有一种模式
必须成对、显式、且仅用于等值比较字段，同时确保两边转换后可安全隐式兼容。例如：
ON CONVERT(t1.name USING utf8mb4) COLLATE utf8mb4_unicode_ci = CONVERT(t2.name USING utf8mb4) COLLATE utf8mb4_unicode_ci
但注意：这本质是靠 CONVERT() 兜底，COLLATE 只负责后续比较行为。单独写 t1.name COLLATE ... = t2.name COLLATE ... 几乎总失败。
实操要点：
- 优先查清两边字段真实校对规则：
SHOW FULL COLUMNS FROM t1 LIKE 'name'，看Collation列 - 如果其中一个是
latin1_swedish_ci，别强行COLLATE utf8mb4_...——字符集不匹配，转换会静默变? -
COLLATE后缀必须和CONVERT(... USING xxx)的字符集一致，否则 MySQL 会再触发一次隐式转换 - 别对
TEXT或BLOB字段直接加COLLATE，它们无默认字符集，必须先CONVERT()
比 COLLATE 更稳的两种做法
临时查数推荐用 CONVERT(col USING utf8mb4)，长期维护必须改表结构。
改表结构（一劳永逸）：
ALTER TABLE t2 MODIFY name VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
临时查询（ON 中只转非驱动表一侧）：
LEFT JOIN t2 ON t1.name = CONVERT(t2.name USING utf8mb4)
关键约束：
- 只在
ON里转，绝不在WHERE里转被 JOIN 的字段（否则索引失效） - 假设
t1是驱动表，那就只转t2.name；反过来则转t1.name - 如果字段允许
NULL，CONVERT(NULL USING ...)还是NULL，逻辑安全；但COLLATE不改变NULL比较语义
ORDER BY 和 GROUP BY 里 COLLATE 的坑
就算 JOIN 成功了，后续 ORDER BY t2.name 仍可能报错或乱序——因为排序字段参与了隐式校对推导，而 JOIN 后的字段元信息没变。
安全做法：
- 在 SELECT 列表中提前转换并起别名：
CONVERT(t2.name USING utf8mb4) COLLATE utf8mb4_unicode_ci AS name_fixed -
ORDER BY name_fixed，避免ORDER BY CONVERT(...)触发Using filesort -
GROUP BY同理，不能依赖隐式转换，必须和 SELECT 中的转换保持一致 - 全文索引字段（
FULLTEXT）完全不支持运行时COLLATE，必须重建索引
最易被忽略的一点：两个字段都是 utf8mb4 字符集，但一个用 utf8mb4_bin、一个用 utf8mb4_unicode_ci，MySQL 依然判定为“非法混合”，不会自动降级兼容——校对规则不一致，等于类型不兼容。
