必须手动定位冲突字段：用SHOW CREATE TABLE对比或查INFORMATION_SCHEMA.COLUMNS获取COLUMN_NAME、CHARACTER_SET_NAME和COLLATION_NAME，确认JOIN/UNION/GROUP BY中外键等参与比较的字段排序规则是否完全一致——字符集相同但collation不同（如utf8mb4_unicode_ci与utf8mb4_0900_ai_ci）即触发报错。
查清哪两个字段在“打架”
报错 SQLSTATE[HY000] [1267] Illegal mix of collations 时，MySQL 不会告诉你具体是哪张表、哪个字段参与了冲突。必须手动定位：先用 SHOW CREATE TABLE t1 和 SHOW CREATE TABLE t2 对比 JOIN 条件里的字段定义；更精准的做法是查 INFORMATION_SCHEMA.COLUMNS：
SELECT COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME IN ('t1', 't2') AND COLUMN_NAME = 'join_field';
重点看 CHARACTER_SET_NAME 和 COLLATION_NAME 是否完全一致——哪怕都是 utf8mb4 字符集，utf8mb4_unicode_ci 和 utf8mb4_0900_ai_ci 也不兼容。
ALTER TABLE MODIFY 才是真正生效的操作
只改连接配置（如 ThinkPHP 的 collation 参数）或在 SQL 里硬加 COLLATE，都不能解决索引失效和报错问题。必须修改字段定义本身：ALTER TABLE t2 MODIFY join_field VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意三点：
• 必须同时指定 CHARACTER SET 和 COLLATE，缺一不可
• 目标 COLLATE 要和关联表对应字段完全一致，别凭印象乱套
• 改完立刻执行 SHOW CREATE TABLE t2 确认字段定义已更新，别只信 SHOW FULL COLUMNS
别忽略外键、UNION 和 GROUP BY 场景
JOIN 字段修好了，不代表万事大吉。以下场景同样受排序规则影响，且容易被跳过：
• 外键约束字段：若 FOREIGN KEY (user_id) REFERENCES users(id) 中两边 COLLATION 不同，建表或插入时直接报 ERROR 1005
• UNION 查询：所有 SELECT 子句中对应列的 COLLATION 必须完全一致，否则报相同错误
• GROUP BY 中文字段：dept_name 在 A 表是 utf8mb4_unicode_ci、B 表是 utf8mb4_general_ci，会导致同一部门名被分到不同组，聚合结果漂移
这些字段往往不显式出现在 JOIN 条件里，但只要参与比较逻辑，就逃不过校对规则校验。
验证是否真修复了
改完不能只跑一条 SELECT 就完事。要分两步验证：
• 性能层面：用原 JOIN SQL 执行 EXPLAIN FORMAT=TREE，确认被驱动表的 type 是 ref 或 eq_ref，key 列显示索引名，而不是 ALL 或空
• 语义层面：跑 SELECT @@collation_connection; 看会话变量是否与你统一后的 COLLATION 匹配；再查 SELECT COUNT(*) FROM t1 JOIN t2 ON t1.f = t2.f 是否不再报错且结果正确
最容易被忽略的是：大表 MODIFY 会锁表重建索引，线上操作务必评估窗口期；而字段若有默认值、生成列或全文索引，需额外处理兼容性。
