改collation_server治标不治本：它仅影响新连接默认collation，对已有表/字段、隐式比较、join/union等无效，无法消除illegal mix of collations错误，且重启后也不更新现存字段collation。
直接改 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 摸清楚。
