MySQL 5.7升级至8.0时，如何解决排序规则不匹配问题？调整collation_server参数是关键。

本文共计718个文字，预计阅读时间需要3分钟。

直接修改 + collation_server + 参数不能解决已存在的排序规则冲突，反而可能隐藏问题、引发新错误。 它只影响新连接的默认 collation，对已有表、字段、查询中的隐式比较无作用——你看到的 Illegal mix of collations 错误根本不会因此消失。

为什么改 collation_server 是治标不治本

MySQL 8.0 的 collation_server 默认是 utf8mb4_0900_as_cs（或 _ai_ci），但这个值只在连接初始化时用于设置 collation_connection，且仅当客户端没显式声明 collation 时才生效。而实际报错场景里：

• 表字段自己带 collation（比如 utf8mb4_general_ci），它优先级高于 collation_server
• 函数返回值（如 CONCAT()、FIND_IN_SET()）有隐式 collation，由上下文决定，不受 collation_server 控制
• JOIN 或 UNION 中两边字段 collation 不一致，MySQL 拒绝自动转换，直接报错

哪些情况看似“有用”，实则危险

有人在 my.cnf 里加了这行：
[mysqld]
collation_server = utf8mb4_unicode_ci
然后发现部分查询不报错了——但这只是把问题从“报错”变成了“静默错误”：

• ORDER BY 结果顺序变了（大小写不再敏感，'A' 和 'a' 被当成相等）
• 唯一索引失效（罗马数字 Ⅰ 和字母 I 再次被允许共存，破坏数据一致性）
• 应用层假设的字符行为（比如前端传来的搜索关键词大小写不敏感）在数据库层被绕过，逻辑错位

真正该做的三件事

定位、收敛、验证，而不是全局覆盖：

• 先查出谁在混用：执行 SHOW FULL COLUMNS FROM your_table;，看每列的 Collation 列，重点关注 utf8mb4_general_ci 和 utf8mb4_0900_ai_ci 并存的表
• 对 JOIN/UNION/FIND_IN_SET 等报错语句，显式统一 collation：ON t1.name COLLATE utf8mb4_0900_ai_ci = t2.name COLLATE utf8mb4_0900_ai_ci
• 批量修复字段（非临时方案）：ALTER TABLE users MODIFY name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;，注意 VARCHAR 长度是否超索引限制（8.0 对前缀索引更严格）

最易被忽略的一点：collation_server 改了之后，必须重启 MySQL 才生效，但即使重启，也不会自动更新任何已有字段的 collation——它只管“新来的”，不管“老住客”。升级后第一要务不是调参数，而是跑一遍 SHOW CREATE TABLE 和 SHOW FULL COLUMNS，把每个表的真实 collation 摸清楚。