正确做法是导出时用 mysqldump 加 --set-gtid-purged=OFF 和 --single-transaction，并确保导入前手动执行 SET FOREIGN_KEY_CHECKS=0，避免因表加载顺序导致 ERROR 1215。
导出时禁用外键检查但不删约束
直接运行 mysqldump 命令，默认会保留外键定义。但问题往往出在导入环节：如果表加载顺序错乱，比如先导入了子表，再导入父表，系统就会抛出 ERROR 1215 (HY000): Cannot add foreign key constraint。这通常不是数据本身的问题，纯粹是加载顺序惹的祸。
所以，正确的思路不是去手动删除外键或修改SQL，而是让导出工具自动帮我们加上 SET FOREIGN_KEY_CHECKS=0 这个开关。这里有几个参数值得关注：
- 使用
--skip-extended-insert能让导出的SQL可读性更好，不过这不是必须项。 - 务必加上
--add-drop-table，这样可以避免残留的旧表结构干扰新数据。 - 最关键的两个参数是
--set-gtid-purged=OFF（如果目标库没有开启GTID）和--single-transaction（用于保证导出的一致性，前提是表引擎为InnoDB）。
一个完整的命令示例如下：
mysqldump --single-transaction --routines --triggers --set-gtid-purged=OFF -u root -p mydb > mydb.sql
导入前确认目标库的 FOREIGN_KEY_CHECKS 状态
即便dump文件里已经包含了 SET FOREIGN_KEY_CHECKS=0 语句，也并非万无一失。尤其是在目标MySQL版本较新（比如8.0.29+）的情况下，如果开启了 require_row_format 或严格模式，这个设置可能会被忽略或中途重置。
为了保险起见，最稳妥的做法是在导入前手动操作一次：
- 连接上目标数据库后，先执行
SET FOREIGN_KEY_CHECKS=0。 - 然后再通过
source mydb.sql或mysql -u root -p mydb < mydb.sql命令导入数据。 - 导入完成后，立即执行
SET FOREIGN_KEY_CHECKS=1重新开启检查，并运行SHOW ENGINE INNODB STATUS来确认没有外键校验失败。
遇到 ERROR 1005 / 1215 时优先查字段类型和索引
外键创建失败，可别全怪加载顺序。更多时候，问题藏在一些隐性的不匹配里。比如说，父表的 id 字段是 BIGINT UNSIGNED，而子表的引用字段却定义成了 BIGINT SIGNED；又或者，父表被引用的列上根本没有建立索引（InnoDB强制要求被引用列必须有索引）。
遇到报错，可以按这个顺序排查：
- 使用
SHOW CREATE TABLE parent_table和SHOW CREATE TABLE child_table仔细对比两个表的字段类型、是否允许NULL、字符集以及排序规则是否完全一致。 - 确认父表被引用的列上存在KEY（即使是主键PRIMARY KEY也算）。
- 检查子表的外键列是否也加了索引（虽然这不是强制要求，但没有索引会导致插入性能极差，甚至引发锁表）。
跨版本迁移时注意 INFORMATION_SCHEMA 兼容性
从MySQL 5.7迁移到8.0，有一个容易踩的坑：INFORMATION_SCHEMA 视图的结构发生了变化。如果你的数据库dump文件中包含了自定义视图或存储过程，并且这些对象依赖了 COLUMNS 或 STATISTICS 等系统表中的特定字段（例如8.0版本中移除了 CHARACTER_SET_NAME 字段），那么导入时就会失败。
如何应对呢？
- 尽量避免在视图或函数里硬编码
INFORMATION_SCHEMA的字段名，可以改用SHOW COLUMNS或更稳定的元数据表接口。 - 如果必须迁移包含复杂视图的数据库，建议先在目标版本的MySQL上执行
mysqldump --no-data --routines --triggers来测试，看能否成功生成基础结构。 - 对于5.7到8.0的迁移，如果是原地升级，可以使用官方的
mysql_upgrade工具；如果是跨主机迁移，则强烈建议使用逻辑导出（即mysqldump）的方式，而不是直接拷贝物理数据文件。
说到底，外键约束本身并不复杂。真正让人头疼的，往往是那些不起眼的细节：字段类型没对齐、索引忘记建，或者以为关了外键检查就一劳永逸——要知道，关闭检查只是绕过了约束验证，并没有解决底层的数据不兼容问题。
