Navicat 还原报错主要因版本兼容问题：① ERROR 1273 源于 MySQL 8.0+ 的 utf8mb4_0900_ai_ci 不被 5.7 识别，需替换为 utf8mb4_unicode_ci；② ERROR 1067 源于 sql_mode 差异，应调整模式或导出设置；③ 卡顿因客户端执行大文件超时，建议用“运行 SQL 文件”并调高超时与 max_allowed_packet。
Navicat 还原时提示 ERROR 1273 (HY000): Unknown collation: 'utf8mb4_0900_ai_ci'
这是 mysql 8.0+ 默认字符集变更导致的典型兼容问题。navicat 导出的备份（尤其来自高版本 mysql）含 utf8mb4_0900_ai_ci 排序规则，而目标库是 mysql 5.7 或更低版本，不识别该 collation。
- 先确认目标 MySQL 版本：
SELECT VERSION();；若低于 8.0，基本无法直接支持utf8mb4_0900_ai_ci - 不要试图在旧版 MySQL 中手动添加 collation——不可行，会报
Unknown collation并中断导入 - 导出端若可控，优先改用兼容模式：在 Navicat「数据传输」或「备份」设置中勾选「兼容 MySQL 5.7」或手动将字符集设为
utf8mb4、排序规则设为utf8mb4_unicode_ci - 若只有 SQL 文件且已报错，用文本编辑器全局替换：
utf8mb4_0900_ai_ci→utf8mb4_unicode_ci（注意保留引号和分号位置）
还原时报 ERROR 1067 (42000): Invalid default value for 'created_at'
本质是 SQL 模式（sql_mode）差异，常见于导出库启用了 STRICT_TRANS_TABLES 或 NO_ZERO_DATE，而目标库未启用，或反之。
- 检查目标库当前模式：
SELECT @@sql_mode;；重点看是否含STRICT_TRANS_TABLES、NO_ZERO_DATE、TRADITIONAL - 临时放宽限制（仅限还原阶段）：
SET sql_mode = 'NO_ENGINE_SUBSTITUTION';，再执行导入 - 更稳妥的做法：导出时在 Navicat「高级」选项里取消勾选「导出表结构中的默认时间值（如 CURRENT_TIMESTAMP）」，避免生成
DEFAULT CURRENT_TIMESTAMP类语句 - 若表中已有
DATETIME字段带NOT NULL但无默认值，旧版 MySQL 可能拒绝空值插入——需提前补默认值或允许 NULL
Navicat 执行 SQL 文件卡住/无响应，日志里没报错
不是语法错误，而是连接或超时配置问题。Navicat 默认使用「查询」方式执行大 SQL，对长事务、大批量 INSERT 不友好。
- 改用「运行 SQL 文件」功能（右键连接 →「运行 SQL 文件」），它走服务端执行，不依赖客户端缓冲
- 检查 Navicat 的「工具 → 选项 → 连接 → MySQL」里「查询超时时间」是否过短（默认 300 秒），可调至 0（不限制）或 3600
- 确认目标库
max_allowed_packet足够大（例如设为256M），否则大 BLOB 或长文本会静默截断 - 若文件含多条语句且含
DELIMITER，Navicat 有时解析失败——建议拆成单个文件，或改用命令行mysql -u root -p
还原后中文乱码，但建表语句里明明写了 CHARSET=utf8mb4
字符集声明只是“告诉 MySQL 这张表想用什么”，真正生效还要看连接层、客户端、服务端三者是否一致。乱码往往卡在连接环节。
- Navicat 连接属性里必须显式设置「字符集」为
utf8mb4（不是utf8！后者在 MySQL 中实际是utf8mb3） - 检查连接建立后的实际变量：
SELECT @@character_set_client, @@character_set_connection, @@character_set_results;，三者应均为utf8mb4 - 若还原后查数据是问号，但
SHOW CREATE TABLE显示正确，大概率是 Navicat 自身编码没切对——重启 Navicat 并重新建连接（别复用旧连接） - MySQL 配置文件（
my.cnf）中，[client]和[mysql]段也需有default-character-set = utf8mb4，否则命令行导入也可能乱码
字符集、SQL 模式、连接参数这三项交叉影响最深，单独调一个往往压不住问题。排查时优先抓日志里第一个报错，它通常是根因；后面一连串错误，常常只是前一个失败引发的连锁反应。
