DISABLE FOREIGN_KEY_CHECKS 在 Navicat 中仅对「数据同步」生效，结构同步中被忽略；混合同步时须先确保结构已存在，且脚本首行为 SET FOREIGN_KEY_CHECKS = 0;，同时需手动调整表创建顺序以满足外键依赖。
DISABLE FOREIGN_KEY_CHECKS 不是开关，是脚本里的一行语句——它是否生效，取决于你同步的是什么、目标库状态如何、以及 Navicat 实际生成的 SQL 是不是真以它开头。
同步类型决定 Disable foreign key checks 是否起作用
这个选项只在「数据同步」中注入 SET FOREIGN_KEY_CHECKS = 0;，且仅对后续的 INSERT/UPDATE 有效。
它在「结构同步」中被完全忽略，Navicat 仍会原样执行 CREATE TABLE ... FOREIGN KEY，MySQL 引擎直接报错 ERROR 1215。
- 如果你在同步结构（比如建新表），勾选该选项毫无意义
- 如果你混选了「结构 + 数据」，Navicat 默认先跑结构部分，此时外键检查未禁用，失败概率极高
- 真正安全的场景只有：目标库已有完整结构，且你只同步数据
验证方式：导出同步脚本（勾选 Generate synchronization SQL script），打开文件确认第一行是 SET FOREIGN_KEY_CHECKS = 0;，且全文没有其他 SET FOREIGN_KEY_CHECKS = 1;
表执行顺序不按依赖来，CREATE TABLE 就会失败
Navicat 不自动解析全库外键依赖树，尤其跨库、旧版本或表名乱序时，Resolve dependencies automatically 基本不可靠。
- 典型报错：
ERROR 1215 (HY000): cannot add foreign key constraint - 原因：先执行
CREATE TABLE orders（引用users），但users表还没建 - 解决必须手动干预：
• 在 Navicat 「对象选择」面板中，把被引用表（如
users、products）拖到引用表（如orders、order_items）上方• 或导出脚本后，用文本编辑器重排
CREATE TABLE语句顺序：父表优先，子表靠后• 查依赖链用：
SELECT TABLE_NAME, REFERENCED_TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME IS NOT NULL;
目标库已有数据时，Disable foreign key checks 反而危险
禁用检查 ≠ 数据合法。如果目标库已存在子表记录，但缺少对应父表主键值，同步时仍会触发 Cannot add or update a child row: a foreign key constraint fails。
- 这类错误不是约束没关掉，而是数据本身有“孤儿行”
- 别急着勾选项，先查问题：
• 找出所有孤儿记录：
SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users);• 若允许清理，用
TRUNCATE而非DELETE清空子表（TRUNCATE绕过外键检查，但要求无活动外键引用）• 若不能删数据，必须先导出父表、再导出子表，分两阶段同步
连接与环境导致 SET FOREIGN_KEY_CHECKS 失效
即使脚本开头写了 SET FOREIGN_KEY_CHECKS = 0;，也可能被覆盖或作用域失效：
- Navicat 默认连接启用了
autocommit = 0，导致SET只对当前事务块有效，后续语句不受影响 - 源库导出的 SQL（如
mysqldump）自带/<em>!40014 SET FOREIGN_KEY_CHECKS = 1 </em>/注释，会在中途强行恢复检查 - MySQL 5.6 或更早版本，在存储过程、事件等上下文中无法动态修改
FOREIGN_KEY_CHECKS
最直接的验证方式：同步失败后立刻连目标库执行 SELECT @@FOREIGN_KEY_CHECKS;，结果必须是 0 才算真正生效——Navicat 从不帮你确认这点。
