navicat结构同步后外键名被重命名，根本原因是其默认不保留原constraint名称，而是按内部模板自动生成（如fk_orders_user_id_2）；需在高级选项中勾选“export foreign keys”和“export foreign key options”，并取消“generate drop statements before create”才能复用原名。
navicat 结构同步后外键名被重命名，不是 bug，而是它默认用自动生成的规则覆盖了原名（比如 fk_orders_user_id_2 替换掉你手动定义的 fk_orders_user_id）。根本原因在于 navicat 在解析和重建外键时，不把原约束名当作不可变元数据，而是当作可被覆盖的“输出项”。
为什么外键名会变：Navicat 不保留 CONSTRAINT 名字
Navicat 的「结构同步」底层逻辑是：读取目标库当前 DDL → 与源库比对差异 → 生成 ALTER/CREATE 语句 → 执行。它并不把 CONSTRAINT xxx 这部分当作必须保留的标识符，尤其当同步设置里没显式要求导出名字时，就会 fallback 到内部命名模板。
- 即使源库 SHOW CREATE TABLE 显示的是
CONSTRAINT fk_user_profile_user_id FOREIGN KEY (user_id) REFERENCES users(id)，Navicat 也可能生成ADD FOREIGN KEY (user_id) REFERENCES users(id)—— 省略CONSTRAINT子句，MySQL 就自动分配新名 - 旧版本 Navicat（如 15 及之前）压根不解析或传输 CONSTRAINT 名称，只认字段引用关系
- 如果目标库已有同名约束但定义不同（比如 ON DELETE 行为变了），Navicat 会先 DROP 再 ADD，而 DROP 语句用了旧名，ADD 却不带名 → 新名诞生
如何让外键名保持不变：必须勾选两个关键选项
不是靠“命名规则设置”，而是靠强制导出并复用原始 CONSTRAINT 定义。操作路径在同步向导的「高级」页（Advanced Options）：
- 勾选
Export foreign keys（确保外键被识别，不是只导表结构） - 勾选
Export foreign key options（这是关键！它控制是否导出ON DELETE CASCADE和CONSTRAINT name） - 取消勾选
Generate DROP statements before CREATE（否则 DROP 会删掉原名，ADD 又没名，必然重命）
注意：Export foreign key options 在 Navicat 16+ 里位于「DDL Options」子页；15 及更早版可能叫 Include constraint names 或藏在「Export settings」里——找不到就搜这个字符串。
同步后仍发现名字变了？检查这三个地方
即便选项全开，名字还是变，大概率是以下某处断链了：
- 源库外键名本身含非法字符（如空格、短横线、中文），Navicat 解析失败后自动 fallback 命名；用
SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'db_name'核对是否合规 - 目标库已存在同名约束，但被其他工具或人工改过定义（比如去掉了
ON UPDATE CASCADE），Navicat 比对后认为“需重建”，DROP 时用了原名，ADD 却因定义不一致拒绝复用 → 强制新名 - 你用的是「数据同步」而非「结构同步」：数据同步不处理外键定义，它只管 INSERT/UPDATE，所以名字变化其实是上一次结构同步遗留的，跟本次操作无关
名字变了会影响什么？别低估这个细节
看起来只是个名字，但实际影响很具体：
- 运维脚本或监控告警依赖
fk_orders_user_id这个精确名称查锁或分析死锁，名字一变就匹配不到 - 某些 ORM（如 Laravel 的
Schema::disableForeignKeyConstraints()）在迁移中会按名禁用特定外键，名不对就禁不掉 - 跨环境部署时，CI/CD 流水线用 SQL 文件做一致性校验，
SHOW CREATE TABLE输出因名字不同直接判定“结构不一致”
所以名字不是装饰，它是约束的唯一身份标识。一旦同步中丢失，后续所有基于名字的自动化操作都可能失效。
