应将sql文件中的utf8mb4_0900_ai_ci替换为utf8mb4_unicode_ci（mysql 5.7推荐）或utf8_general_ci（5.6及更早），同时确保character set与collate匹配，避免混用utf8mb4字符集与utf8排序规则。
直接删掉 sql 文件里所有 utf8mb4_0900_ai_ci 和 utf8mb4_0900_as_cs，替换成目标 mysql 版本真正支持的 collation —— 不是“改错”，而是“降级适配”。
导入报 Unknown collation: 'utf8mb4_0900_ai_ci' 怎么办
这是 MySQL 5.7 或更老版本不认识 MySQL 8.0 新增排序规则的典型表现。不是文件损坏，也不是权限问题，纯粹是版本不兼容。
- 先确认目标 MySQL 版本：
mysql --version或执行SELECT VERSION(); - MySQL 5.7：统一替换为
utf8mb4_unicode_ci（比utf8mb4_general_ci更准，且广泛兼容） - MySQL 5.6 及更早：必须降级到
utf8_general_ci，同时把所有CHARSET=utf8mb4改成CHARSET=utf8 - 别用正则盲目替换整个文件——先 grep 确认范围：
grep -n "utf8mb4_0900" dump.sql
为什么不能只改 COLLATE 不动 CHARACTER SET
MySQL 要求 collation 必须属于对应 character set。把 utf8mb4_0900_ai_ci 强行塞进 CHARACTER SET utf8 的表定义里，会触发 ERROR 1253 (HY000)。
- 查建表语句里是否混用：
CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8mb4_0900_ai_ci→ 这种写法本身非法 - 安全做法：先统一删掉显式
COLLATE子句，让 MySQL 用库/表默认规则；或同步修正CHARSET和COLLATE - 如果目标库已建好且设为
utf8mb4，就只换 collation；如果目标库还是utf8，就得连 charset 一起降
导入前加 SET NAMES utf8mb4 有用吗
没用。这条语句只影响客户端连接层的字符集协商，对 CREATE TABLE 里硬编码的 CHARSET 和 COLLATE 完全无效。
- 真正起作用的是建表语句本身的定义，不是会话变量
- 导入命令里加
--default-character-set=utf8mb4也仅控制连接，不覆盖 SQL 文件里的显式声明 - 唯一可靠方式：改 SQL 文件，或提前建好目标库并指定默认字符集（
CREATE DATABASE db_name DEFAULT CHARSET utf8mb4 COLLATE utf8mb4_unicode_ci）
已经导入失败，但部分表建好了怎么办
别用 ALTER DATABASE CONVERT TO CHARACTER SET —— 它会二次破坏已有乱码数据。
- 先查哪些表中招：
SELECT table_name, table_collation FROM information_schema.tables WHERE table_schema = 'your_db' AND table_collation LIKE '%0900%'; - 逐个修正：
ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 注意：如果字段内容已是乱码（比如中文变问号），CONVERT 无法恢复，得从备份重导
最麻烦的不是替换字符串，而是得判断每处 utf8mb4_0900_* 出现在什么上下文里——建库、建表、建字段、索引、视图、函数，不同位置的修复逻辑可能差一拍。动手前先 head -50 dump.sql 看开头结构，比盲目全文替换安全得多。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
