必须手动控制SQL文件头尾+关闭错误跳过+验证目标库状态，因Navicat的“Disable foreign key checks”仅在数据同步中插入SET语句，不保证生效，且易被覆盖或忽略。
直接结论：只勾选“disable foreign key checks”几乎没用，必须手动控制 sql 文件头尾 + 关闭错误跳过 + 验证目标库实际状态。
为什么 Navicat 的 “Disable foreign key checks” 常常失效
这个选项仅在「数据同步」类型下起作用，且只影响脚本开头是否插入 SET FOREIGN_KEY_CHECKS = 0;。但它不保证该语句生效，常见失效场景包括：
- 目标库是 MySQL 5.6 或更早版本，
FOREIGN_KEY_CHECKS在某些上下文中无法动态修改 - 源 SQL 文件里自带
SET FOREIGN_KEY_CHECKS = 1;（比如从mysqldump导出再导入），它会覆盖 Navicat 插入的禁用语句 - 你实际执行的是「结构同步」而非「数据同步」——该选项在此类任务中被完全忽略
- Navicat 连接启用了
autocommit = 0，导致SET语句只对当前事务块有效，后续 DML 不受其影响
真正有效的三步操作（缺一不可）
要让外键约束真正被绕过，必须同时完成以下动作：
- 导出 SQL 脚本时，在「转储 SQL 文件」→「高级」中勾选
Add SET FOREIGN_KEY_CHECKS=0（不是“Disable foreign key checks”） - 手动打开生成的 SQL 文件，确认第一行是
SET FOREIGN_KEY_CHECKS = 0;，且最后一行是SET FOREIGN_KEY_CHECKS = 1;；中间不能有其他SET FOREIGN_KEY_CHECKS = 1; - 导入时，在「运行 SQL 文件」对话框右下角取消勾选
遇到错误继续执行——否则ERROR 1215或ERROR 1050会被静默吞掉，你以为成功了，其实关键表根本没建出来
导入后必须验证是否真的生效
别信 Navicat 的“执行完成”提示，它不反映真实状态。导入完成后立刻执行：
SELECT @@FOREIGN_KEY_CHECKS;
结果必须是 0 才说明禁用成功。如果返回 1，说明目标库未执行或覆盖了你的 SET 语句，常见于：
- 目标库账户权限不足（如只读用户），
SET被拒绝但无报错 - 使用了数据库代理（如 ProxySQL），它过滤或重写了
SET类语句 - SQL 文件里存在多个
SET，最后一个恰好是= 1
真正容易被忽略的是：即使外键检查关了，表结构顺序、字符集、存储引擎不一致照样导致失败——FOREIGN_KEY_CHECKS 只管引用完整性，不管这些底层兼容性问题。
