navicat导出时需手动设置sql兼容模式为目标版本（如mysql 5.7），并调整字符集、禁用不兼容语法，导入前还需核对连接参数及前置执行set命令以避免语法误判。
navicat导出时选错“源服务器类型”会导致导入失败
navicat 的「转储sql文件」功能默认按当前连接的数据库版本和类型生成语句，但如果你是从 mysql 8.0 导出、却要导入到 mysql 5.7 或 mariadb，而导出时没指定兼容目标，就会生成 utf8mb4_0900_ai_ci、create or replace view、json_contains() 等不被旧版本识别的语法。这不是编码或内存问题，是源头生成逻辑错了。
关键点在于：Navicat 不会自动降级语法，它只忠实地反映“源服务器”的能力。你必须手动告诉它“我要兼容谁”。
- 右键数据库 →「转储SQL文件」→ 进入「高级」选项卡
- 找到
SQL兼容模式下拉菜单，不要用默认的MySQL 8.0，改选MySQL 5.7（或对应目标版本） - 同时检查
字符集声明是否设为utf8mb4_unicode_ci（5.7 兼容）而非utf8mb4_0900_ai_ci - 取消勾选「导出视图定义」或「导出存储过程」，除非确认目标环境完全支持
导入前验证 SQL 文件是否含不兼容语法
即使导出时设了兼容模式，仍可能漏掉隐式依赖。比如 CREATE TABLE t2 AS SELECT * FROM t1 要求 t1 必须已存在，但 Navicat 默认按对象类型分块导出（先表、再视图、再数据），顺序未必合理。
直接打开 SQL 文件搜索这几类关键词，比等报错后再排查快得多：
- 搜
utf8mb4_0900_ai_ci—— 替换为utf8mb4_unicode_ci（用 Notepad++ 或 VS Code 批量替换） - 搜
CREATE OR REPLACE—— 改成DROP TABLE IF EXISTS+CREATE TABLE - 搜
JSON_开头的函数（如JSON_CONTAINS）—— 旧版 MySQL 不支持，需改写或删掉相关字段 - 搜
ALTER TABLE ... ALTER COLUMN—— MySQL 5.7 不支持该语法，应改为MODIFY COLUMN或CHANGE COLUMN
Navicat「运行SQL文件」里没填对连接参数也会触发语法误判
Navicat 在执行 SQL 文件时，会把整个文件发给服务端解析。如果连接属性里没明确指定服务器类型和版本，它可能用错协议协商逻辑，导致某些语句被截断或注释失效。
务必检查连接的「高级」设置页：
-
服务器类型必须与目标 MySQL 实际版本一致（不是 Navicat 版本，也不是你本地装的 MySQL 版本，而是你要连的那个库的版本） -
字符集填utf8mb4，不是utf8（后者在 MySQL 中实际是 utf8mb3） -
max_allowed_packet设为1073741824（即 1G），否则大 INSERT 语句会被截断，报错像Packets larger than max_allowed_packet - 取消勾选
每个运行中运行多重查询—— 防止一条失败就中断全部，也避免事务边界混乱
最容易被忽略的点：SQL 文件开头的 SET 语句可能覆盖连接设置
有些 Navicat 导出的 SQL 文件开头带 SET NAMES utf8mb4; 或 SET sql_mode=...;。如果这些语句和你的目标库不兼容（比如设置了 STRICT_TRANS_TABLES，但表结构含零日期），导入会在第一行就失败。
解决方法不是删掉它们，而是前置干预：
- 在 Navicat 的「运行 SQL 文件」窗口中，勾选
在执行前运行自定义命令 - 填入：
SET SESSION sql_mode = '';和SET NAMES utf8mb4;（注意顺序：先清 mode，再设 names） - 确保这个自定义命令比 SQL 文件里的任何
SET都早执行
真正的坑不在文件多大，而在你有没有意识到：Navicat 导出和导入是两个独立决策点，各自都要对准目标环境。错一个，就全盘语法不认。
