必须用“数据传输”功能导出带外键的多张表，因“转储sql文件”不保证父子表顺序、不处理跨库/复合外键依赖、不校验字符集一致性，易导致导入报错error 1215或悬空引用。
必须用“数据传输”功能，其他路径导出的外键约束会丢失或不完整。
为什么不能用“转储SQL文件”导出带外键的多张表
“转储SQL文件”默认按表顺序生成 CREATE TABLE 语句，但不会自动调整外键引用顺序。比如子表依赖父表，而父表语句在子表之后，导入时会报 ERROR 1215: Cannot add foreign key constraint。即使勾选了“导出外键”，Navicat 15 不保证语句执行顺序，也不处理跨库外键或复合外键的依赖闭环。
- 外键字段字符集/排序规则不一致（如
utf8mb4_unicode_civsutf8_general_ci）时，“转储SQL”仍会导出语句，但导入必然失败 - 若某张子表外键引用了已删除的列，转储结果里仍保留该外键定义，属于“假成功”
- 不支持对目标库预检：无法提前发现目标库缺少对应引擎（如目标是 MyISAM）、无权限建外键等硬限制
用“数据传输”导出多表结构+外键的实操要点
这是唯一能保持外键完整性、自动处理依赖顺序、且支持跨库映射的方式。关键不是“导出”，而是把源库当“源”，把本地文件或空目标库当“目标”来走一遍传输流程。
- 顶部菜单 →
工具→数据传输 - “源”选当前连接 + 目标数据库；“目标”选
文件（导出为 SQL），或另一个空数据库连接（直接同步） - 点击
选项→ 在“记录选项”中取消勾选“创建记录”（这是只导结构的核心开关） - 在对象列表页，勾选所有要导出的表（支持 Ctrl 多选），确保父子表都在同一轮操作中被选中
- 点
下一步后，在“高级”页确认勾选了导出外键、导出索引、导出注释；添加 DROP TABLE按需勾选（仅用于覆盖导入场景）
导出后验证外键是否真被包含
别只看文件大小或是否生成成功。打开导出的 SQL 文件，搜索 FOREIGN KEY，再人工核对两件事：
- 每个
CONSTRAINT名是否唯一？重复名会导致导入时报ERROR 1022 - 所有
REFERENCES后的库名.表名.字段名，是否在当前导出范围内真实存在？跨库外键若没被一并选中，这里就是悬空引用 - 检查开头是否有
SET FOREIGN_KEY_CHECKS = 0;和结尾的= 1;—— 缺失意味着导入时可能因约束冲突中断
导出 HTML 表结构文档时外键信息不显示怎么办
Navicat 15 的「导出向导 → HTML」只渲染单表字段和索引，完全不包含外键信息。这不是 bug，是设计如此。ER 图里的连线、外键标签页里的定义，都不会进 HTML 表格。
- 如果需要带外键关系的文档，只能改用「数据库字典」→ 导出为 HTML（全库级，含外键章节，但字段注释折叠在二级菜单）
- 或者手动执行 SQL 查询
SELECT TABLE_NAME, COLUMN_NAME, CONSTRAINT_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db' AND REFERENCED_TABLE_NAME IS NOT NULL;，再导出结果为 Excel - 切勿指望右键单表 → 导出向导 → HTML 能看到外键——它连主键约束都只标个 PK 字样，更别说外键细节
外键不是“导出来就行”，而是“导出来还能被正确重建”。很多团队卡在导入阶段才发现外键没生效，根源往往在导出时没意识到 Navicat 对依赖顺序和字符集一致性是静默忽略的。
