正确做法是导出时用 mysqldump 加 --set-gtid-purged=OFF 和 --single-transaction，并确保导入前手动执行 SET FOREIGN_KEY_CHECKS=0，避免因表加载顺序导致 ERROR 1215。
导出时禁用外键检查但不删约束
直接 mysqldump 默认会保留外键定义，但导入时若表顺序错乱（比如先导入子表再导入父表），就会报 ERROR 1215 (HY000): Cannot add foreign key constraint。这不是数据问题，是加载顺序问题。
正确做法是在导出时让 mysqldump 自动加 SET FOREIGN_KEY_CHECKS=0，而不是手动删外键或改 SQL：
- 用
--skip-extended-insert可读性更好，但非必须 - 务必加
--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 - 导入完成立即执行
SET FOREIGN_KEY_CHECKS=1并运行SHOW ENGINE INNODB STATUS查看是否有外键校验失败
遇到 ERROR 1005 / 1215 时优先查字段类型和索引
外键失败不全是顺序问题，更多是隐性不匹配：比如父表 id 是 BIGINT UNSIGNED，子表引用字段却是 BIGINT SIGNED；或者父表没给 id 加索引（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或元数据表接口 - 若必须迁移含复杂视图的库，先在目标版本上执行
mysqldump --no-data --routines --triggers看能否生成基础结构 - 5.7 → 8.0 迁移建议用
mysql_upgrade（仅限原地升级），跨主机迁移请用逻辑导出而非物理文件拷贝
外键本身不难处理，真正卡住人的往往是字段类型对不齐、索引漏建、或者以为关了检查就万事大吉——其实关检查只绕过约束验证，不解决底层不兼容。
