COLLATE强制指定仅在字符集相同、仅校对规则不同、仅用于等值比较、成对且完全一致、NULL语义一致时才安全有效；否则仍报错或无法走索引。
为什么在ON子句里加
经常不生效
直接写
看似能绕过错误，但 MySQL 实际执行前会先做隐式校对推导——只要两边字段原始
不同，优化器就可能拒绝该表达式，仍报
。更糟的是，即使语法通过，加了
的字段无法走索引，
里
会变成
或显示
。
哪些场景下
强制指定才真能用
仅当以下条件全部满足时，
才是安全的临时手段：
两个字段字符集相同（比如都是
），只是校对规则不同（如
vs
）
只用于
或
中的等值比较，不用在
、
或
列上
必须成对出现，且后缀完全一致（不能一边写
，另一边写
）
字段本身允许
且两侧语义一致，否则
比较逻辑可能被干扰
怎么查清当前字段的真实
别信“看起来都是 utf8mb4”，得看实际定义：
React Native For Android 源码编译 中文WORD版
本文档主要讲述的是React Native For Android 源码编译；希望对大家会有帮助；感兴趣的朋友可以过来看看
下载
用
查
列值
对比
和
，重点看字段定义末尾的
注意：MySQL 8.0+ 默认新表用
，老表可能是
，二者不兼容
比
更稳的解法：改表结构
临时加
是补丁，长期靠
统一：
先确认目标校对规则，比如统一为
执行
—— 必须显式写出类型、字符集、校对规则三者
改完立刻跑
确认字段定义已更新，别只看
再执行原 SQL 并
，检查
是否命中索引、
是否为
或
真正容易被忽略的点是：外键字段、
字段、甚至全文索引字段，只要参与字符串比较，都得同步处理
。只改
条件里的字段，其他地方照样崩。
COLLATEt1.name COLLATE utf8mb4_unicode_ci = t2.name COLLATE utf8mb4_unicode_ciCOLLATIONIllegal mix of collationsCOLLATEEXPLAINtypeALLUsing join bufferCOLLATECOLLATEutf8mb4utf8mb4_general_ciutf8mb4_0900_as_csONWHEREGROUP BYORDER BYUNIONutf8mb4_unicode_ciutf8mb4_0900_ai_ciNULLNULL = NULLCOLLATIONSHOW FULL COLUMNS FROM t1 LIKE 'item_code'CollationSHOW CREATE TABLE t1SHOW CREATE TABLE t2COLLATE xxxutf8mb4_0900_as_csutf8mb4_general_ciCOLLATECOLLATEALTER TABLE MODIFYutf8mb4_0900_as_csALTER TABLE t2 MODIFY item_code VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_csSHOW CREATE TABLE t2SHOW FULL COLUMNSEXPLAIN FORMAT=TREEkeytyperefeq_refUNIONCOLLATIONON