Navicat导出SQL默认不包含外键，需在导出向导「高级选项」中手动勾选“导出外键”和“导出索引”，并确保源库权限、驱动兼容性及字段类型符合要求，否则外键不会生成。
导出SQL时外键消失，不是漏了，是根本没开开关
navicat 默认不导出外键，哪怕表里明明确确建好了。它把「约束」和「结构」当成两层东西处理，而导出向导的默认路径只拉取最基础的 create table 和字段定义——foreign key 子句压根不在这个通道里。
关键动作在「高级选项」卡里，不是「模型生成SQL」那个入口（那是设计界面预览用的），而是导出向导中选择「SQL文件」格式后弹出的设置面板：
- 必须勾选
导出外键（选项名可能显示为 “Export foreign keys” 或带锁图标的复选框） - 同时确认
导出索引也已勾选，否则INDEX和UNIQUE KEY同样不会出现 - 如果目标库是 PostgreSQL，MySQL 特有的
ENGINE=InnoDB和ON DELETE CASCADE位置会被自动重写或丢弃——这不是 bug，是 Navicat 主动做语法兼容裁剪
导出前先验证外键是否真被 Navicat 识别到了
有时候你勾了「导出外键」，结果还是空——大概率是 Navicat 根本没读到外键元数据。原因很实在：
- 源库用户缺少
SELECT ON information_schema.*权限，KEY_COLUMN_USAGE视图查不到，外键链直接断掉 - MySQL 5.6 及更早版本不支持
REFERENCED_COLUMN_NAME字段，Navicat 15+ 驱动会静默降级，不报错但也不生成外键 - 主表字段是
TEXT或BLOB类型，MySQL 原生不支持对外键字段建索引，Navicat 检测到后跳过整条外键解析
快速验证方法：在源库执行 SHOW CREATE TABLE t_orders;，看输出里有没有 CONSTRAINT `fk_user_id` FOREIGN KEY ... 行。如果有，但 Navicat 导出没写进去，问题一定出在权限或驱动兼容性上。
同步结构时外键报错，关检查 ≠ 解决问题
同步时报 Cannot add or update a child row: a foreign key constraint fails，很多人第一反应是去勾 Disable foreign key checks——这确实能让脚本跑通，但容易埋雷：
- 它只禁用检查，不解决依赖顺序；Navicat 不会自动重排表同步顺序，仍可能先建
orders再建users - 若源库 SQL 文件里混着
SET FOREIGN_KEY_CHECKS = 1，它会在中途强行恢复约束，导致后半段失败 - MySQL 5.7+ 的 InnoDB 对
SET FOREIGN_KEY_CHECKS = 0的作用域更敏感，旧版 Navicat 可能只对单条语句生效，而非整个事务块
稳妥做法是：先纯结构同步（不勾选「同步数据」），启用 Generate DROP statements before CREATE，再手动确保父表在子表之前出现在对象列表里——拖动排序比依赖自动解析可靠得多。
导入SQL后外键没生效，别急着重试
导入完执行 SHOW CREATE TABLE t_orders;，发现还是没 FOREIGN KEY？常见干扰项有三个：
-
在每行运行中多个查询这个选项开着，Navicat 把ALTER TABLE ... ADD FOREIGN KEY和前面的CREATE TABLE合并执行，中间遇到分号或注释就截断，外键语句直接被吞掉 - 目标库已有同名约束，比如之前建过又删了，但 Navicat 缓存了旧名，新语句因
CONSTRAINT `fk_user_id`重复被 MySQL 忽略 - 导入时用了
TRUNCATE TABLE清空旧表——哪怕关了外键检查，MySQL 仍拒绝 TRUNCATE 被外键引用的表，整个事务可能卡住或静默跳过
真正要盯住的，不是“点了没”，而是最终 SHOW CREATE TABLE 输出里有没有那行 CONSTRAINT。没有，就说明 SQL 没执行成功，或者执行了但被服务端拒收了——这时候翻日志比点重试有用。
