COLLATE强制指定仅在字符集相同、仅校对规则不同、仅用于等值比较、成对且完全一致、NULL语义一致时才安全有效；否则仍报错或无法走索引。
为什么在ON子句里加COLLATE经常不生效
直接写 t1.name COLLATE utf8mb4_unicode_ci = t2.name COLLATE utf8mb4_unicode_ci 看似能绕过错误，但 MySQL 实际执行前会先做隐式校对推导——只要两边字段原始 COLLATION 不同，优化器就可能拒绝该表达式，仍报 Illegal mix of collations。更糟的是，即使语法通过，加了 COLLATE 的字段无法走索引，EXPLAIN 里 type 会变成 ALL 或显示 Using join buffer。
哪些场景下COLLATE强制指定才真能用
仅当以下条件全部满足时，COLLATE 才是安全的临时手段：
- 两个字段字符集相同（比如都是
utf8mb4），只是校对规则不同（如utf8mb4_general_civsutf8mb4_0900_as_cs） - 只用于
ON或WHERE中的等值比较，不用在GROUP BY、ORDER BY或UNION列上 - 必须成对出现，且后缀完全一致（不能一边写
utf8mb4_unicode_ci，另一边写utf8mb4_0900_ai_ci） - 字段本身允许
NULL且两侧语义一致，否则NULL = NULL比较逻辑可能被干扰
怎么查清当前字段的真实COLLATION
别信“看起来都是 utf8mb4”，得看实际定义：
- 用
SHOW FULL COLUMNS FROM t1 LIKE 'item_code'查Collation列值 - 对比
SHOW CREATE TABLE t1和SHOW CREATE TABLE t2，重点看字段定义末尾的COLLATE xxx - 注意：MySQL 8.0+ 默认新表用
utf8mb4_0900_as_cs，老表可能是utf8mb4_general_ci，二者不兼容
比COLLATE更稳的解法：改表结构
临时加 COLLATE 是补丁，长期靠 ALTER TABLE MODIFY 统一：
- 先确认目标校对规则，比如统一为
utf8mb4_0900_as_cs - 执行
ALTER TABLE t2 MODIFY item_code VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs—— 必须显式写出类型、字符集、校对规则三者 - 改完立刻跑
SHOW CREATE TABLE t2确认字段定义已更新，别只看SHOW FULL COLUMNS - 再执行原 SQL 并
EXPLAIN FORMAT=TREE，检查key是否命中索引、type是否为ref或eq_ref
真正容易被忽略的点是：外键字段、UNION 字段、甚至全文索引字段，只要参与字符串比较，都得同步处理 COLLATION。只改 ON 条件里的字段，其他地方照样崩。
