必须先导入父表再导入子表，否则因父表不存在触发ERROR 1215；mysqldump默认按字母序导出不保证依赖顺序，云数据库常禁用FOREIGN_KEY_CHECKS写权限，导入前须手动执行SET FOREIGN_KEY_CHECKS=0且确保其在整个导入会话中生效。
先导入父表再导入子表，否则会报 ERROR 1215
外键约束要求被引用的父表必须先存在、且数据就位，否则 mysqldump 导出的 CREATE TABLE 语句在导入时就会失败。这不是数据问题，是建表顺序错乱导致的硬性限制。
常见错误现象：ERROR 1215 (HY000): Cannot add foreign key constraint，尤其在用 Navicat 或 DBeaver 手动拖拽导入多个 SQL 文件时高频出现。
- 用
mysqldump --databases导出时，默认按字母序导出表，不保证依赖顺序；即使加了--order-by-primary也解决不了外键依赖问题 - 若目标库已存在部分表（比如只删了数据没删结构），
--add-drop-table可能误删父表，导致后续子表建表失败 - 云数据库（如阿里云 RDS、腾讯云 TDSQL-C）通常禁用
FOREIGN_KEY_CHECKS写权限，必须提前确认是否允许执行SET FOREIGN_KEY_CHECKS=0
导入前必须手动执行 SET FOREIGN_KEY_CHECKS=0
别依赖 dump 文件里的 SET FOREIGN_KEY_CHECKS=0 —— 它只对当前 SQL 文件内生效，而 mysql 客户端默认以单条语句方式执行，遇到分号就结束会话上下文。尤其当你用 mysql -e "source xxx.sql" 或程序调用时，该 SET 会被忽略。
正确做法是：连接目标库后，第一件事就是运行：
SET FOREIGN_KEY_CHECKS = 0;
然后再执行导入命令（如 mysql -u root -p mydb ）。导入完成后，立刻执行：
SET FOREIGN_KEY_CHECKS = 1;
并紧接着运行 SHOW ENGINE INNODB STATUS 查看是否有外键校验失败残留。
字段类型和索引不匹配才是 ERROR 1215 的真正高发原因
哪怕顺序完全正确、FOREIGN_KEY_CHECKS 关闭了，仍可能报 ERROR 1215。这时候不是顺序问题，而是隐性不一致。
排查要点：
- 用
SHOW CREATE TABLE parent_table和SHOW CREATE TABLE child_table对比：两表中对应字段是否都是BIGINT UNSIGNED（不能一个SIGNED一个UNSIGNED） - 字符集和排序规则必须完全一致，比如
utf8mb4_0900_ai_ci和utf8mb4_unicode_ci不兼容 - 父表被引用列必须有索引（
PRIMARY KEY或UNIQUE KEY都行，但普通KEY不够） - 子表外键列建议显式加索引，否则大量 INSERT 会锁表或超慢——InnoDB 不强制要求，但不加等于埋雷
跨版本迁移时外键定义可能被静默忽略
MySQL 8.0.29+ 在开启 require_row_format 或严格模式下，会跳过 dump 文件中的 SET FOREIGN_KEY_CHECKS=0，直接按当前会话设置校验。更麻烦的是，如果源库是 5.7、目标库是 8.0，某些外键语法（比如带 ON UPDATE CASCADE 的旧写法）可能被拒绝。
应对策略：
- 导出时明确加
--set-gtid-purged=OFF（目标库没开 GTID 时）和--single-transaction（仅限 InnoDB） - 避免用
--skip-foreign-key-checks—— 它只是在 dump 头部加SET，不是“绕过外键”，别被名字误导 - 若目标库引擎是 MyISAM，
mysqldump仍会导出FOREIGN KEY语句，但导入时直接报错；必须提前用 sed 或脚本删掉所有CONSTRAINT和FOREIGN KEY字段定义
最易被忽略的一点：外键约束本身可以重建，但历史脏数据不会自动修复。比如源库曾绕过约束插入过孤立子记录，导入后 SET FOREIGN_KEY_CHECKS=1 会失败，必须先清理或补全父表数据。
