mysql 8.0默认排序规则是utf8mb4_0900_ai_ci，非utf8_general_ci；它基于unicode 9.0标准，准确支持德语ß、emoji、中文扩展字符等，而utf8mb4_general_ci已被官方弃用，存在排序错误和兼容性风险。
MySQL 8.0 的默认排序规则没从 utf8_general_ci 变——它压根就没用过这个规则作为 utf8mb4 字符集的默认值。
MySQL 8.0 默认的是 utf8mb4_0900_ai_ci，不是 utf8_general_ci
你看到的“变化”，其实是两个不同层级的切换：
-
utf8_general_ci对应的是utf8字符集（MySQL 里的阉割版 UTF-8，最多 3 字节），它在 MySQL 5.5.3 之前是默认字符集，但早已被弃用； - MySQL 5.5.3 起引入
utf8mb4，并把它的默认排序规则设为utf8mb4_general_ci； - MySQL 8.0.1 才把
utf8mb4的默认排序规则从utf8mb4_general_ci升级为utf8mb4_0900_ai_ci。
所以真正发生变更的是：utf8mb4_general_ci → utf8mb4_0900_ai_ci，不是 utf8_general_ci。
utf8mb4_0900_ai_ci 比 utf8mb4_general_ci 强在哪？
核心是 Unicode 标准支持和语言行为准确性：
-
utf8mb4_general_ci是个“查表硬凑”的老算法：比如'ß' = 'SS'返回1（错误），德语里 ß 确实等价于 ss，但它没按标准实现； -
utf8mb4_0900_ai_ci基于 Unicode 9.0 归类算法（UCA 9.0.0）：正确处理德语 ß、法语 ç、越南语重音、emoji 排序，'ä'和'a'不再被当成相等； - 它还修复了中文生僻字、CJK 扩展区汉字的排序逻辑，不再简单依赖 Unicode 码点顺序。
升级后报 Illegal mix of collations 怎么办？
这是最常见也最容易踩坑的问题：服务端默认用 utf8mb4_0900_ai_ci，但你的表或字段还是 utf8mb4_general_ci，MySQL 在隐式比较时直接拒绝执行。
- 查问题根源：
SHOW CREATE TABLE your_table;看表和各字段的COLLATE是否混用； - 临时修复（不推荐长期用）：
SELECT ... WHERE col COLLATE utf8mb4_general_ci = 'x'； - 彻底解决：统一升级字段排序规则，例如：
ALTER TABLE t MODIFY name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;； - 注意：
CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci会重建所有字符列，大表要评估锁和耗时。
新项目到底该选哪个？
除非你明确要兼容 MySQL 5.7 或更早版本，否则别犹豫：utf8mb4_0900_ai_ci 是唯一合理选择。
- MySQL 官方已将
utf8mb4_general_ci标记为deprecated，后续版本会移除； - 它不支持 Unicode 9.0+ 的语言特性，连基本的大小写等价都靠查表模拟，出错概率高；
- 性能差距在现代硬件上几乎不可测，所谓“general_ci 更快”只在百万级简单 LIKE 查询中略显优势，代价却是搜索不准、排序错乱、用户投诉。
真正容易被忽略的点是：排序规则一旦写进建表语句，就会影响索引结构和查询计划。改的时候不只是“换个名字”，得验证 ORDER BY、GROUP BY、JOIN ON、WHERE = / LIKE 的行为是否一致——尤其当字段参与联合索引时。
