直接改collation_server参数不能解决报错，因它仅影响新连接默认排序规则，对已有字段、JOIN、FIND_IN_SET或隐式比较无效；MySQL 8.0默认排序规则升级为utf8mb4_0900_ai_ci，但老表仍用旧collation，跨表比较时collation不一致即报Illegal mix of collations。
直接改 collation_server 参数不能解决报错，它只影响新连接的默认排序规则，对已有字段、JOIN、FIND_IN_SET 或隐式比较完全无效。
为什么升级后突然报 Illegal mix of collations
MySQL 8.0 默认排序规则从 utf8mb4_general_ci（5.7 常用）切换为 utf8mb4_0900_ai_ci（基于 Unicode 9.0，更严格）。但这个变更只作用于新创建的表/列；老表仍保留原 collation。一旦查询中涉及跨表比较（如 JOIN、UNION、FIND_IN_SET()、子查询），两边字段 collation 不一致，MySQL 就拒绝自动转换，直接抛出错误。
- 常见触发点：
WHERE t1.col = t2.col、NOT IN (SELECT ...)、FIND_IN_SET(col, @var)、ORDER BY涉及多源字段 - 注意：即使两个字段都是
utf8mb4字符集，只要 collation 不同（比如一个是_general_ci，另一个是_0900_ai_ci），就会冲突 -
CONCAT()、IF()等函数返回值的 collation 由上下文推导，也可能引入隐式不一致
为什么 collation_server 是个危险的“止痛药”
在 my.cnf 里加 collation_server = utf8mb4_unicode_ci 后部分查询看似不报错了，其实是掩盖了问题：
-
ORDER BY结果顺序可能变（大小写/重音敏感性被绕过） - 唯一索引失效：原本因 collation 区分大小写而保证唯一的字段（如
'I'和罗马数字'Ⅰ'），现在可能被当成相同值插入 - 应用层假设的语义被破坏：前端传来的搜索关键词本应大小写不敏感，但数据库实际执行时却按新规则做了区分
- 重启后不会更新现存字段的 collation，旧数据仍处于混用状态
怎么快速定位哪些地方在混用 collation
别猜，直接查真实结构：
- 看表字段：执行
SHOW FULL COLUMNS FROM your_table;，重点关注Collation列，找同时存在utf8mb4_general_ci和utf8mb4_0900_ai_ci的表 - 看建表语句：执行
SHOW CREATE TABLE your_table;，确认CHARACTER SET和COLLATE是否显式声明，是否统一 - 查报错 SQL 中涉及的所有表和字段，逐个比对 collation，尤其注意子查询、临时变量、函数返回值的隐式 collation 来源
真正该做的三件事：定位 → 收敛 → 验证
临时修复只能靠显式强制统一 collation，长期必须批量收敛字段定义：
- 对报错 SQL，加
COLLATE显式指定：例如ON t1.name COLLATE utf8mb4_0900_ai_ci = t2.name COLLATE utf8mb4_0900_ai_ci - 批量修复字段：用
ALTER TABLE t MODIFY col VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;，注意VARCHAR长度不能导致前缀索引超限（8.0 对索引长度更敏感） - 验证不能只看“不报错”：要检查
ORDER BY排序是否符合业务预期、唯一约束是否仍生效、大小写敏感场景是否逻辑一致
最容易被忽略的是：你看到的 SHOW VARIABLES LIKE 'collation%' 全是连接或服务器级设置，它们和具体字段的 collation 没有继承关系——每个字段的 collation 是独立存储在表结构里的，必须一个个查、一个个改。
