set foreign_key_checks=0仅适用于纯数据导入，结构同步时会导致外键漏建；应按依赖顺序建表、启用export foreign keys和generate drop语句、检查级联选项与存储引擎。
直接执行 set foreign_key_checks = 0 并不能一劳永逸解决 navicat 导入时的外键报错，反而可能掩盖更关键的问题——比如建表顺序错误、约束定义不一致、或数据本身就不满足引用完整性。这个语句只在「纯数据插入」阶段临时绕过校验，对结构同步（create table、alter table add constraint）几乎无效，甚至会让约束漏建。
为什么只设 FOREIGN_KEY_CHECKS = 0 常常没用
Navicat 默认导出的 SQL 文件里，如果包含建表语句，往往会在开头或结尾自动带上 SET FOREIGN_KEY_CHECKS = 1 ——它会把你的手动设置覆盖掉。尤其是从 MySQL 5.7+ 导出的备份，很可能自带 /*!40014 SET FOREIGN_KEY_CHECKS = 1 */ 这类条件注释，执行时照样触发约束检查。
另外，如果你同步的是结构+数据混合脚本，FOREIGN_KEY_CHECKS = 0 只能跳过 INSERT 阶段的校验，但无法解决「先建 orders 表、后建 users 表」这类 DDL 顺序问题；MySQL 在 CREATE TABLE orders (...) FOREIGN KEY (user_id) REFERENCES users(id) 时仍会报错，因为 users 表还不存在。
真正该做的：分清场景再动手
判断你当前操作属于哪一类，再选对应解法：
- 如果是「仅导入数据」（目标库已有结构，只插记录）：确认目标库确实执行了
SET FOREIGN_KEY_CHECKS = 0，且该会话未被 Navicat 自动重置；建议在 Navicat 的「运行 SQL 文件」窗口顶部手动粘贴并执行这行，再点执行文件 - 如果是「结构同步」（用「结构同步」向导）：必须勾选
Disable foreign key checks（位置在同步窗口右下角 → 「高级」→「SQL 选项」），而不是自己写 SET 语句；否则 Navicat 生成的 SQL 不会包含禁用逻辑 - 如果是「跨库迁移」（如 SQL Server → MySQL）：Navicat 不解析异构依赖，
FOREIGN_KEY_CHECKS设置完全无效；得先用源库查出依赖顺序（如 SQL Server 的sp_fkeys），手动排序建表语句再导入
容易被忽略的三个硬性前提
就算关了检查，以下几点不满足，照样失败：
-
ENGINE必须都是InnoDB：MyISAM 表加不了外键，SHOW CREATE TABLE 表名看不到ENGINE=InnoDB就得先改 - 字段类型和长度要严格一致：比如
INT(11) UNSIGNED和INT(11)不兼容，VARCHAR(50) utf8mb4和VARCHAR(50) utf8也不行 - 子表外键字段必须有索引：Navicat 不一定自动建，得自己补
CREATE INDEX idx_表名_字段名 ON 表名(字段名)，否则 MySQL 5.7+ 可能静默拒绝加约束
最麻烦的不是怎么关检查，而是关了之后发现数据对不上、约束没生效、或者级联动作（ON DELETE CASCADE）根本没写进 DDL ——这些都得靠 SHOW CREATE TABLE 对比源库和目标库来验证，不能只信 Navicat 界面显示的“成功”。
