典型报错是error 1215或error 1005，主因是外键列与被引用列在类型、长度、符号、字符集、排序规则五项上未逐字匹配，如int与int unsigned不兼容、varchar(32)与varchar(64)不兼容、utf8mb4_unicode_ci与utf8mb4_general_ci视为不一致。
外键字段类型不匹配的典型报错是什么
Navicat 15 正向工程或手动建表时，如果外键列和被引用列类型不一致，MySQL 服务端会直接拒绝建表，报 ERROR 1005（errno 150）或 ERROR 1215。你看到的“保存失败”或“Can't create table”只是表层提示，真正卡点在字段定义细节上——比如一个 INT(11) UNSIGNED 去关联 INT(11)，Navicat 界面里都显示为“int”，但 MySQL 认为完全不兼容。
这类问题不会在 Navicat 模型校验阶段暴露，只有执行 SQL 时才触发，所以别信“模型看起来没问题”。
怎么快速定位两个字段是否真的一致
别只看 Navicat 表设计界面右下角写的“类型”，要查实际 DDL 定义：
- 右键主表 →「对象信息」→ 切到「DDL」页，复制建表语句，找被引用字段的完整定义，例如：
id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT
- 同样查子表外键字段定义，对比以下五项是否逐字相同：
COLUMN_TYPE、IS_NULLABLE、COLLATION_NAME（字符集排序规则）、EXTRA（如 unsigned 或 auto_increment）、CHARACTER_SET_NAME
- 用命令确认：
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE, COLLATION_NAME, EXTRA FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME IN ('parent', 'child') ORDER BY TABLE_NAME;
id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT
COLUMN_TYPE、IS_NULLABLE、COLLATION_NAME（字符集排序规则）、EXTRA（如 unsigned 或 auto_increment）、CHARACTER_SET_NAME
SELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE, COLLATION_NAME, EXTRA FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME IN ('parent', 'child') ORDER BY TABLE_NAME;
特别注意：INT 和 INT UNSIGNED 是两种类型；VARCHAR(32) 和 VARCHAR(64) 不行；utf8mb4_unicode_ci 和 utf8mb4_general_ci 视为不兼容。
Navicat 15 里改字段类型最稳妥的操作路径
图形界面修改容易漏掉隐性属性，建议分步手动修正：
- 先在主表确保被引用字段是
PRIMARY KEY 或已有独立 INDEX（Navicat 不会自动加索引，得自己点「索引」页签添加）
- 右键子表 →「设计表」→ 选中外键字段 → 在下方属性栏逐项对齐：勾/不勾
Unsigned、设相同 Length、选一致 Collation、调整 Not Null 状态（两边必须同为 NOT NULL 或同为允许 NULL）
- 导出前务必进「工具」→「选项」→「建模」→ 勾选
Generate foreign keys inside CREATE TABLE statement，避免外键被拆成单独 ALTER 导致静默失败
- 如果已存在数据，且字段类型差异大（如
INT → BIGINT），先用 ALTER TABLE child MODIFY COLUMN fk_col BIGINT UNSIGNED; 改子表，再同步主表，否则 ALTER 会因数据不兼容中止
PRIMARY KEY 或已有独立 INDEX（Navicat 不会自动加索引，得自己点「索引」页签添加）Unsigned、设相同 Length、选一致 Collation、调整 Not Null 状态（两边必须同为 NOT NULL 或同为允许 NULL）Generate foreign keys inside CREATE TABLE statement，避免外键被拆成单独 ALTER 导致静默失败INT → BIGINT），先用 ALTER TABLE child MODIFY COLUMN fk_col BIGINT UNSIGNED; 改子表，再同步主表，否则 ALTER 会因数据不兼容中止改完别急着点保存，点「SQL 预览」看生成语句里外键定义是否带完整约束，尤其是 REFERENCES parent(id) 后有没有多出意外的 ON DELETE SET NULL（当字段是 NOT NULL 时这句必报错）。
为什么改了类型还是报错？检查这三个隐藏点
很多用户改完类型仍失败，往往栽在这三处：
-
ENGINE 不统一：两张表必须都是 InnoDB。用 SHOW CREATE TABLE parent; 和 SHOW CREATE TABLE child; 对比，若出现 ENGINE=MyISAM，立刻执行 ALTER TABLE table_name ENGINE=InnoDB;
- 字符集层级冲突：表级
COLLATE 和字段级 COLLATE 必须一致。Navicat「表属性」→「选项」页设置表级 Collation 后，还要进「字段」页单独点每个字段，确认其 Collation 没被设成别的值
- 外键名重复：Navicat 15 默认生成类似
fk_child_parent_id 的名字，但如果库中已有同名约束（哪怕已删），MySQL 仍会拒绝。解决方法是在外键编辑框里手动输入新名字，比如加时间戳后缀：fk_child_parent_id_202606
ENGINE 不统一：两张表必须都是 InnoDB。用 SHOW CREATE TABLE parent; 和 SHOW CREATE TABLE child; 对比，若出现 ENGINE=MyISAM，立刻执行 ALTER TABLE table_name ENGINE=InnoDB;
COLLATE 和字段级 COLLATE 必须一致。Navicat「表属性」→「选项」页设置表级 Collation 后，还要进「字段」页单独点每个字段，确认其 Collation 没被设成别的值fk_child_parent_id 的名字，但如果库中已有同名约束（哪怕已删），MySQL 仍会拒绝。解决方法是在外键编辑框里手动输入新名字，比如加时间戳后缀：fk_child_parent_id_202606
外键不是模型画完就自动生效的逻辑线，它是 MySQL 服务端一条条硬校验的规则。Navicat 只是生成 SQL 的前端，所有不一致都会在执行瞬间被拦住——所以别怪工具，盯紧字段定义里的每一个空格和括号。
