MySQL迁移需全程禁用外键检查：导出前执行SET FOREIGN_KEY_CHECKS=0，导入后执行SET FOREIGN_KEY_CHECKS=1，并用CHECK TABLE验证一致性；跨版本或引擎迁移须检查并清理外键定义。
导出时禁用外键检查再还原
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验证外键一致性，尤其当源库曾绕过约束写入过脏数据
dump 的外键相关参数组合
单纯加 --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 定义，导致导入报错或静默忽略。
AI人声去除器和声乐提取工具
- 迁移前用
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 全部执行成功，也可能存在逻辑上的“断裂”。每次迁移后都应抽样比对关键外键路径的数据可达性，而不是只看是否报错。
