17370845950

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 验证外键一致性，尤其当源库曾绕过约束写入过脏数据

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 全部执行成功，也可能存在逻辑上的“断裂”。每次迁移后都应抽样比对关键外键路径的数据可达性，而不是只看是否报错。