Navicat结构同步不单独识别外键语义差异，需直查information_schema元数据比对CONSTRAINT_NAME、REFERENCED_TABLE_NAME、DELETE_RULE等字段；SHOW CREATE TABLE输出一致不代表外键真实生效，须验证字段类型、字符集及索引是否兼容。
navicat 本身不提供“外键约束差异对比”功能——它只比结构（show create table）和数据，不单独提取、解析、比对外键定义的语义变化。 想知道两个库中同一张表的外键是否一致、增删或行为变更（比如 on delete cascade 改成 no action），得绕过界面，直查元数据。
为什么结构同步里看不到外键差异？
Navicat 的「结构同步」把外键当作表定义的一部分来比对，但有严重盲区：
- 它不单独高亮外键字段或约束名变更，比如把
fk_orders_customer_id改成fk_orders_client_id，可能被归为“表结构整体不同”，不提示具体是外键名变了 - 如果两个库中表的外键都存在，但
ON DELETE行为不同（如库A是CASCADE，库B是SET NULL），结构同步通常不会识别为差异——因为SHOW CREATE TABLE输出里这两者语法不同，但 Navicat 的语义比对逻辑对约束行为识别不敏感 - 若目标库外键被手动
DROP过，而源库还有，结构同步可能生成ADD CONSTRAINT，但不会告诉你“原来这里有个外键，现在没了”，除非你提前知道该表该有外键
真正能查清外键差异的 SQL 写法
别依赖图形界面，用以下查询直接比对 information_schema.KEY_COLUMN_USAGE 和 REFERENTIAL_CONSTRAINTS：
SELECT kcu.CONSTRAINT_NAME, kcu.COLUMN_NAME, kcu.REFERENCED_TABLE_NAME, kcu.REFERENCED_COLUMN_NAME, rc.UPDATE_RULE, rc.DELETE_RULE FROM information_schema.KEY_COLUMN_USAGE kcu JOIN information_schema.REFERENTIAL_CONSTRAINTS rc ON kcu.CONSTRAINT_NAME = rc.CONSTRAINT_NAME WHERE kcu.TABLE_SCHEMA = 'your_db' AND kcu.TABLE_NAME = 'orders';
对两个库分别执行，再人工比对结果。重点看：
-
CONSTRAINT_NAME是否一致（命名差异=约束被重建过） -
REFERENCED_TABLE_NAME和REFERENCED_COLUMN_NAME是否指向相同父表/字段 -
DELETE_RULE和UPDATE_RULE值是否相同（CASCADE/SET NULL/NO ACTION）
外键字段类型不一致时，Navicat 完全不报错但实际建不起来
这是最隐蔽的“伪一致”场景：两个库的 SHOW CREATE TABLE 都显示有外键，但目标库其实根本没生效——因为字段类型不兼容：
- 源库子表外键是
BIGINT UNSIGNED，父表主键是BIGINT→ 不匹配，MySQL 拒绝约束，但 Navicat 结构同步仍会显示“无差异” - 字符集不同：子表字段用
utf8mb4_0900_ai_ci，父表用utf8mb4_general_ci→ 外键创建失败，SHOW CREATE TABLE里也不显示FOREIGN KEY，但 Navicat 可能因缓存误判为“已存在” - 验证方式：在目标库执行
SHOW CREATE TABLE orders，确认输出里真有CONSTRAINT `fk_orders_customer_id` FOREIGN KEY (...) REFERENCES `customers` (`id`)这一行；没有，就说明外键压根没建成功
ER 图连线颜色 ≠ 外键定义一致
Navicat 的模型图里红色/橙色/灰色连线，只反映当前库中**已生效**外键的 ON DELETE 行为，但它不校验：
- 该外键是否在另一库中也存在（图是单库渲染的）
- 父表字段是否真被索引（InnoDB 要求被引用列必须有索引）
- 跨库外键是否引用了不存在的数据库（比如
db1.orders.customer_id → db2.customers.id，但目标库没连db2）
所以看到 ER 图有红线，不代表另一库也有同行为外键——它只是本地元数据的快照，不是对比结果。
