导出时禁用外键检查再还原
MySQL 默认在导入时会校验外键约束，如果表顺序不对或数据缺失，会直接报错
ERROR 1217 (HY000): Cannot delete or update a parent row: a foreign key constraint fails。最稳妥的做法是在导出和导入全程关闭外键检查。
导出前执行：
SET FOREIGN_KEY_CHECKS = 0;导入 SQL 后、验证数据前执行：
SET FOREIGN_KEY_CHECKS = 1;必须在同一个会话中执行，否则
SET不生效；用
mysqldump --skip-foreign-key-checks参数导出时，它会在 dump 文件开头自动加上
SET FOREIGN_KEY_CHECKS=0，但仅限于该文件内生效 如果用
mysql -e "source xxx.sql"方式导入，
SET语句不会跨命令生效，建议改用
mysql 或在 SQL 文件首尾显式控制迁移完成后务必手动运行
CHECK TABLE验证外键一致性，尤其当源库曾绕过约束写入过脏数据
mysqldump 的外键相关参数组合
单纯加
--skip-foreign-key-checks并不能解决所有问题——它只跳过导入时的约束检查，不处理建表顺序。真正影响还原成功率的是
--add-drop-table和
--disable-keys的配合，以及是否启用
--databases模式。
mysqldump --databases --single-transaction --routines --triggers --set-gtid-purged=OFF db1 db2是较安全的全量导出组合；
--single-transaction能保证一致性，且默认包含
SET FOREIGN_KEY_CHECKS=0如果目标库已有部分表结构，避免用
--add-drop-table（会删表重来），改用
--no-create-info+ 手动建表，否则外键依赖的父表可能被后删，导致重建失败
--skip-foreign-key-checks实际上等价于在 dump 头部插入
SET FOREIGN_KEY_CHECKS=0，它本身不是 mysqldump 的独立开关，不要误以为加了就“彻底无视外键”
跨版本或跨引擎迁移时外键失效风险
MySQL 5.7 升级到 8.0 后，
STRICT_TRANS_TABLES模式更严格，某些原本能插入的空外键值（如
NULL引用）可能被拒绝；InnoDB 表迁到 MyISAM 更危险——MyISAM 完全不支持外键，但
mysqldump仍会导出
FOREIGN KEY定义，导致导入报错或静默忽略。 迁移前用
SELECT TABLE_NAME, ENGINE, CREATE_OPTIONS FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'db_name';检查引擎一致性 对 MyISAM 目标库，必须提前用正则删掉 dump 文件中的所有
FOREIGN KEY和
CONSTRAINT字段定义，否则会卡在语法错误 MySQL 8.0.19+ 默认开启
require_row_format，若源库有压缩行格式（
ROW_FORMAT=COMPRESSED）而目标库未启用
innodb_file_per_table，外键关联的索引可能无法创建，需同步调整配置
增量同步阶段外键更新的原子性陷阱
使用
pt-online-schema-change或
gh-ost做在线 DDL 时，如果操作涉及外键列（如修改主键、删除被引用字段），工具默认不校验外键依赖，容易造成从库复制中断或数据不一致。
gh-ost从 v1.0.49 开始支持
--allow-on-master+
--hooks-path插入预检查脚本，可在 cut-over 前执行
SELECT COUNT(*) FROM child_table WHERE parent_id NOT IN (SELECT id FROM parent_table)防止孤儿记录 用
binlog解析做增量同步时，
UPDATE外键列的事件若拆成两行（先删子记录、再插新记录），而中间被
STOP SLAVE中断，会导致从库短暂丢失关联关系 最保险的方式是：在业务低峰期停写，用
FLUSH TABLES WITH READ LOCK锁住所有相关表，再启动同步，而不是依赖工具自动处理外键依赖链 外键迁移真正的难点不在语法层面，而在约束状态与数据实际一致性的错位——哪怕 SQL 全部执行成功，也可能存在逻辑上的“断裂”。每次迁移后都应抽样比对关键外键路径的数据可达性，而不是只看是否报错。
