报错“Unknown collation: 'utf8mb4_0900_ai_ci'”表明目标MySQL 5.7不兼容8.0新增排序规则，需全局替换为utf8mb4_unicode_ci，并检查DEFAULT CURRENT_TIMESTAMP等不兼容语法。
Navicat导入SQL报错“语法错误”但脚本本身没改过
这不是你写错了，大概率是导出端和目标库版本不匹配。mysql 5.7 导出的脚本在 8.0+ 上通常能跑，反过来却常失败——高版本语法（比如 json 字段定义、create table ... default current_timestamp）或排序规则（utf8mb4_0900_ai_ci）在旧版里直接被当语法错误处理。
关键判断点：打开 SQL 文件，搜 utf8mb4_0900_ai_ci、CURRENT_TIMESTAMP、JSON、GENERATED ALWAYS AS 这类词。只要出现且目标库是 MySQL 5.7 或更早，基本就是它了。
检查并替换不兼容的排序规则 utf8mb4_0900_ai_ci
报错 ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci' 是最典型的信号，说明目标 MySQL 版本不识别这个 8.0+ 新增的 collation。
- 先确认目标库版本：
SELECT VERSION(); - 若结果是
5.7.x或更低，别折腾配置，直接文本替换 - 用 VS Code 或 Notepad++ 打开 SQL 文件，全局替换：
utf8mb4_0900_ai_ci→utf8mb4_unicode_ci（注意保留引号和分号位置） - 别只换一处——建库、建表、修改表语句里都可能出现，建议开启“全文件高亮”再扫一遍
处理 DEFAULT CURRENT_TIMESTAMP 类型的默认值报错
报错类似 ERROR 1067 (42000): Invalid default value for 'created_at'，本质不是语法错，而是 sql_mode 限制变严了。MySQL 5.7 默认启用 STRICT_TRANS_TABLES，而 8.0+ 导出的脚本常带 DEFAULT CURRENT_TIMESTAMP，旧版认为这是“非法默认值”。
- 临时绕过（仅限还原阶段）：
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';，填入 Navicat “运行 SQL 文件”窗口的「执行前运行自定义命令」框 - 更干净的做法：提前在目标库执行
SET SESSION sql_mode = '';，再导入 - 长期方案：导出时在 Navicat 勾掉「导出表结构中的默认时间值」，避免生成这类语句
为什么用“运行 SQL 文件”比“粘贴执行”更可靠
很多人把 SQL 复制进查询编辑器执行，结果卡住、断连、报错行号对不上——这是因为粘贴执行走的是客户端解析 + 逐条发送，大文件容易超时、编码错乱、事务中断；而“运行 SQL 文件”是服务端直读，跳过客户端缓冲和语法预检。
- 必须用右键连接 →「运行 SQL 文件」，不是「新建查询」→ 粘贴
- 导入前务必勾选「使用 UTF-8 编码读取文件」，且文件本身要存为
UTF-8 无 BOM - 大文件记得调高 Navicat 的「查询超时时间」（设为 0）和目标库的
max_allowed_packet（至少 256M）
真正麻烦的从来不是语法本身，而是版本差异藏在默认值、collation、sql_mode 这些开关里——它们不报“语法错误”，但让语法错误成为必然结果。
