MySQL 5.7导入8.0报“Unknown collation: 'utf8mb4_0900_ai_ci'”是因导出SQL含8.0新增排序规则，5.7不识别；应导出时用--compatible=mysql57，或替换为utf8mb4_unicode_ci等兼容collation。
MySQL 5.7 导入到 8.0 报 Unknown collation: 'utf8mb4_0900_ai_ci'
这是跨大版本迁移最常撞上的墙：低版本导出的 sql 里写了高版本才有的排序规则，老 mysql 直接不认识。不是字符集问题，是 collation 名字变了——utf8mb4_0900_ai_ci 在 5.7 根本不存在。
实操建议：
- 别改源库或硬升级目标库，直接处理 SQL 文件更可控
- 用
sed或编辑器全局替换时，只换 collation 名，不动CHARACTER SET部分（比如保留utf8mb4） - 常见映射：
utf8mb4_0900_ai_ci→utf8mb4_unicode_ci（5.7 兼容，语义接近）；utf8mb4_0900_as_cs→utf8mb4_bin - 如果原库其实是 5.7 导出的，却出现
_0900_*，说明导出时用了 8.0+ 的mysqldump，下次加--compatible=mysql57
mysqldump 导出时就该避开排序规则陷阱
等导入报错再修，不如导出时就切掉隐患。关键是让 dump 工具“装作”自己是老版本。
实操建议：
- 强制指定兼容模式：
mysqldump --compatible=mysql57 --default-character-set=utf8mb4 - 禁用新 collation 输出：
--skip-set-charset配合手动加SET NAMES utf8mb4更稳妥 - 不加
--no-tablespaces时，5.7 导入 8.0 可能因表空间定义冲突失败，建议显式加上 - 如果用的是 DMS、Navicat 等图形工具，检查导出设置里有没有“兼容性模式”开关，别只盯着字符集
ALTER TABLE 时提示 Unknown collation 但表明明存在
不是导入，是运行时执行 ALTER TABLE ... CONVERT TO CHARACTER SET 或修改列 collation 报错。本质是语句里写了目标实例不支持的 collation 字符串。
实操建议：
- 先查目标实例支持哪些：
SHOW COLLATION WHERE Charset = 'utf8mb4';，别凭记忆写 - 避免直接写
COLLATE utf8mb4_0900_ai_ci，改用COLLATE utf8mb4_unicode_ci或COLLATE utf8mb4_general_ci（后者已弃用但 5.7 全支持） - 如果必须用严格大小写敏感排序，
utf8mb4_bin是最安全的跨版本 fallback - 注意：
CONVERT TO会重写整张表，生产环境慎用；单改列用MODIFY COLUMN ... COLLATE ...更轻量
docker 或云数据库里找不到 my.cnf 怎么统一设默认 collation
容器或托管服务常不让你碰配置文件，但又希望新库/新表默认用兼容 collation，不能每次建表都手写。
实操建议：
- 启动容器时用
--character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci覆盖默认值 - 云数据库（如阿里云 RDS）在参数模板里找
collation_server和character_set_server，设成utf8mb4_unicode_ci - 如果只能连上去执行命令，
SET PERSIST collation_server = 'utf8mb4_unicode_ci';（8.0+），5.7 用SET GLOBAL但重启失效 - 注意：
PERSIST值写入mysqld-auto.cnf，某些容器镜像挂载时可能被清空，得配合初始化脚本重置
真正麻烦的不是替换字符串，而是同一个 collation 名在不同版本里行为可能有细微差异——比如 utf8mb4_unicode_ci 在 5.7 和 8.0 对某些 emoji 的比较结果就不完全一致。如果业务依赖精确排序，光换名字不够，得测关键 case。
