navicat 15 默认按 mysql 8.0+ 兼容性导出 sql，含 utf8mb4_0900_ai_ci、default current_timestamp 等 5.7 不支持特性，需全局替换为 utf8mb4_unicode_ci、utf8 及兼容默认值，并临时调整 sql_mode 后用“运行 sql 文件”导入。

navicat 15 默认按 mysql 8.0+ 兼容性导出，直接导入 mysql 5.7 几乎必报错——不是脚本写错了，是它根本没打算兼容你这台老库。

为什么 Navicat 15 导出的 SQL 在 MySQL 5.7 上跑不起来

Navicat 15 的「模型转 SQL」或「备份数据库」功能默认启用 MySQL 8.0+ 特性：建表语句里带 DEFAULT CURRENT_TIMESTAMP、ON UPDATE CURRENT_TIMESTAMP、utf8mb4_0900_ai_ci 排序规则，甚至可能含 JSON 字段定义。MySQL 5.7 不认识这些，一读就卡在语法解析阶段，报 ERROR 1273 (HY000): Unknown collation 或 ERROR 1067 (42000): Invalid default value。

关键判断方式：用文本编辑器打开导出的 .sql 文件，搜索以下关键词：

• utf8mb4_0900_ai_ci
• DEFAULT CURRENT_TIMESTAMP
• ON UPDATE CURRENT_TIMESTAMP
• JSON
• GENERATED ALWAYS AS

只要目标库是 5.7.x，出现任意一个，基本就是根源。

必须全局替换的三个核心项

别只改第一处——这些词会分散在 CREATE DATABASE、CREATE TABLE、ALTER TABLE 多个位置。用 VS Code / Notepad++ 开启“全文件高亮”再操作：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 把所有 utf8mb4_0900_ai_ci 替换为 utf8mb4_unicode_ci（保留引号和分号）
• 把所有 utf8mb4（单独成词、后跟空格或括号的）替换为 utf8；但注意别误伤字段名如 user_utf8mb4_tag
• 把所有 DEFAULT CURRENT_TIMESTAMP 和 ON UPDATE CURRENT_TIMESTAMP 整行删掉，或替换成兼容写法，例如：DEFAULT '0000-00-00 00:00:00'（需配合后续 sql_mode 调整）

导入前必须绕过的 sql_mode 限制

MySQL 5.7 默认开启严格模式，其中 NO_ZERO_DATE 和 STRICT_TRANS_TABLES 会让 DEFAULT '0000-00-00 00:00:00' 直接被拒。临时解法最稳：

• 在 Navicat 的「运行 SQL 文件」窗口中，勾选「执行前运行自定义命令」，填入：SET SESSION sql_mode = 'NO_ENGINE_SUBSTITUTION';
• 或者更彻底一点：SET SESSION sql_mode = '';（清空当前会话模式）
• 不建议改全局 sql_mode，因为会影响其他应用；也不建议永久改 my.cnf，容易引发线上副作用

比“粘贴执行”更可靠的导入方式

千万别把大 SQL 复制进查询编辑器里点执行——客户端会逐条解析、超时中断、编码错乱，错误行号对不上，还容易卡死。必须用 Navicat 的「运行 SQL 文件」功能（右键连接 → “运行 SQL 文件”），它走服务端直读，跳过客户端缓冲和预检，成功率高得多。

如果连这个都失败，说明文件里还有隐藏坑：比如建库语句遇到 ERROR 1007: database exists，就提前手动删库；或者字段类型用了 TIMESTAMP(0) 这种 5.7 不支持的精度写法，得手动删掉括号里的 (0)。