报错“Illegal mix of collations”需先用SHOW CREATE TABLE定位JOIN字段的排序规则，再通过COLLATE子句显式统一（如u.email COLLATE utf8mb4_unicode_ci = o.customer_email COLLATE utf8mb4_unicode_ci），优先选兼容性强的utf8mb4_unicode_ci；长期应ALTER TABLE修改列COLLATION，注意锁表与索引重建风险。
MySQL报错“Illegal mix of collations”时怎么快速定位问题字段
JOIN失败通常不是语法错，而是两边字段的collation不兼容。比如utf8mb4_unicode_ci和utf8mb4_general_ci看似同源，但MySQL不允许直接比较；更常见的是一边是utf8mb4_0900_as_cs（区分大小写），另一边是utf8mb4_unicode_ci（不区分）。执行SHOW CREATE TABLE table_name，重点看JOIN涉及的列（尤其是ON条件里的）的COLLATION值，别只看CHARSET——字符集相同，排序规则不同照样报错。
用COLLATE子句临时统一排序规则（最常用解法）
不需要改表结构，加COLLATE强制转码即可。注意必须加在字段表达式右侧，且两边都要显式指定（否则隐式转换仍可能失败）：
SELECT * FROM users u JOIN orders o ON u.email COLLATE utf8mb4_unicode_ci = o.customer_email COLLATE utf8mb4_unicode_ci;
关键点：
-
COLLATE必须写在字段名后、比较符前，不能写在等号右边整体上 - 选哪个collation？优先用双方都支持的、较宽松的，如
utf8mb4_unicode_ci比utf8mb4_0900_as_cs兼容性更好 - 如果字段本身是
TEXT或JSON类型，某些collation不支持，会报Unsupported collation，此时换用utf8mb4_bin
ALTER TABLE修改列的COLLATION（长期方案）
频繁JOIN又总要加COLLATE，说明设计层面不一致，该统一了。改单列最安全：
ALTER TABLE users MODIFY email VARCHAR(255) COLLATE utf8mb4_unicode_ci;
注意风险：
- 执行会锁表（尤其大表），建议在低峰期操作
- 如果该列有索引，
MODIFY会重建索引，耗时明显；可用ALTER TABLE ... CONVERT TO CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci批量改全表，但影响更大 - 应用层若依赖大小写敏感逻辑（比如密码哈希存的是小写），改成
_ci后可能出bug，得同步检查业务代码
为什么LEFT JOIN比INNER JOIN更容易暴露collation问题
因为LEFT JOIN中右表字段可能为NULL，而NULL参与collation比较时行为更敏感。例如：u.name COLLATE utf8mb4_unicode_ci = o.name在o.name IS NULL时，若o.name的collation是utf8mb4_0900_as_cs，MySQL可能拒绝隐式转换，直接报错；而INNER JOIN因过滤掉NULL行，反而“侥幸”通过。所以测试阶段务必用真实含NULL的数据跑一遍LEFT JOIN逻辑。
真正麻烦的不是报错本身，而是线上服务里某个JOIN突然慢几秒再报错——那往往是因为MySQL在尝试做隐式collation转换时卡住了。宁可一开始就显式写COLLATE，也别赌它能自动对齐。
