MySQL在JOIN时因字段COLLATION不兼容直接报错ERROR 1267，根源是表结构中CHARACTER SET和COLLATE定义不一致，而非连接层编码或SQL写法问题，必须通过ALTER TABLE MODIFY统一字段定义。
为什么JOIN字段字符集不一致会直接报错
不是所有字符集冲突都只慢，有些直接拦在执行前——MySQL 在解析 = 或 JOIN 条件时，发现两边字段的 COLLATION 不兼容，就拒绝比较，抛出 ERROR 1267: Illegal mix of collations。
典型场景是：左表字段用 utf8mb4_general_ci，右表同名字段用 utf8mb4_0900_ai_ci，哪怕值都是 'abc'，MySQL 也不认为它们“可比”，因为校对规则底层实现不同（比如大小写敏感性、重音处理逻辑），无法安全隐式对齐。
- 报错不是数据问题，是元信息冲突：
SHOW CREATE TABLE里看字段定义末尾的COLLATE值，只要不完全相同，就可能触发 -
IMPLICIT标识说明冲突发生在隐式推导阶段，不是你写了CONVERT才出问题，而是 MySQL 自动尝试转换失败 - 错误位置常在
ON子句或WHERE中的等值判断，但根源在字段定义，不是 SQL 写法本身
为什么只改连接层编码没用
有人试过在客户端加 SET NAMES utf8mb4 或 JDBC URL 里配 characterEncoding=utf8mb4，结果照样报错——因为连接层只影响传入 SQL 的解析和返回结果的编码，不影响表结构里已固化的 COLLATION 定义。
真正起作用的是字段定义里的 CHARACTER SET 和 COLLATE，MySQL 在 JOIN 前会先校验这两个属性是否兼容，不通过就终止，根本不进执行器。
-
SELECT @@character_set_client, @@character_set_connection, @@character_set_results只能查当前会话编码，不能掩盖表字段的 COLLATION 差异 - MyBatis 或 Spring JdbcTemplate 报错堆栈里出现
Illegal mix of collations，说明问题已在服务端 SQL 解析阶段发生，跟 ORM 层无关 - 即使所有表都设了
DEFAULT CHARSET=utf8mb4，已有字段仍保留建表时的旧COLLATE，必须显式ALTER TABLE ... MODIFY
为什么在 ON 里硬加 COLLATE 通常无效
写成 ON t1.code COLLATE utf8mb4_0900_ai_ci = t2.code COLLATE utf8mb4_0900_ai_ci 看似能过语法，但多数情况下索引依然失效，甚至仍报错。
原因在于：MySQL 优化器会在执行前做表达式归约，一旦发现原始字段 COLLATION 不同，就会拒绝该等值条件的索引下推；就算侥幸走索引，加 COLLATE 的表达式也无法命中 B+ 树索引，因为索引是按字段原始排序规则构建的。
- 正确做法是统一字段定义：
ALTER TABLE t2 MODIFY code VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci，必须同时指定CHARACTER SET和COLLATE -
MODIFY比CHANGE更安全，不改列名，避免触发外键或触发器异常 - 改完立刻用
SHOW CREATE TABLE t2确认，别只信SHOW FULL COLUMNS，后者有时缓存旧值
外键、UNION、全文索引也受同样规则约束
这些地方不显式写 JOIN，但内部一样做字符串比对，COLLATION 不一致照样崩。
比如外键字段 t1.user_id 引用 t2.id，如果两者 COLLATE 不同，建表时就会报 ERROR 1005: Can't create table；UNION 要求所有 SELECT 列的字符集和排序规则完全一致，否则直接报错；MATCH ... AGAINST 字段若 COLLATE 不匹配，全文检索结果为空或不准。
- 真正容易被忽略的是：这些字段往往不在日常查询里显式出现，但只要表结构存在，就随时可能被关联或约束触发
- 修复时不能只盯 JOIN 语句涉及的字段，得查
INFORMATION_SCHEMA.KEY_COLUMN_USAGE和INFORMATION_SCHEMA.STATISTICS，把外键、索引、全文字段全扫一遍
