迁移前须执行SET FOREIGN_KEY_CHECKS = 0;，且必须配对执行SET FOREIGN_KEY_CHECKS = 1;，因其仅对当前会话生效，连接复用可能导致约束长期关闭。
迁移前先禁用外键检查，但必须配对恢复
MySQL 迁移时外键报错（如 Cannot add or update a child row: a foreign key constraint fails）往往不是数据问题，而是导入顺序或约束检查未关闭。执行迁移前务必在目标库运行：
SET FOREIGN_KEY_CHECKS = 0;但关键点在于：它只对当前会话生效，且必须在导入完成后立即恢复，否则后续写入可能破坏数据一致性。恢复命令是
SET FOREIGN_KEY_CHECKS = 1;，不能依赖会话自动断开——有些客户端（如某些 GUI 工具或连接池）会复用连接，导致约束长期处于关闭状态。
mysqldump 导出时加 --skip-foreign-key-checks 不起作用
mysqldump 命令本身没有 --skip-foreign-key-checks 这个参数，常见误操作。真正有效的组合是：
mysqldump --no-create-info --skip-triggers --set-gtid-purged=OFF -u user -p db_name table1 table2 > data.sql然后手动在
data.sql 开头插入 SET FOREIGN_KEY_CHECKS = 0;，结尾插入 SET FOREIGN_KEY_CHECKS = 1;。如果导出含建表语句（--no-create-info 未加），还要注意 CREATE TABLE 语句中自带的 ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 等参数是否与目标库兼容，否则外键虽不报错，但表实际没启用 InnoDB，外键形同虚设。
跨版本迁移时外键名长度和字符集要对齐
MySQL 5.7 和 8.0 对外键名长度限制不同（前者最多 64 字符，后者 64 字节，UTF8MB4 下一个汉字占 4 字节），若原库外键名含中文且接近长度上限，导入 8.0 会报错 Identifier name 'xxx' is too long。解决方法不是删外键，而是重命名后导出：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id;
ALTER TABLE orders ADD CONSTRAINT fk_usr_id FOREIGN KEY (user_id) REFERENCES users(id);同样，若源库用
utf8（实为 utf8mb3），目标库默认 utf8mb4，外键字段的字符集、排序规则（collation）必须完全一致，否则创建外键失败，错误信息类似 ERROR 1822 (HY000): Failed to add the foreign key constraint. Missing index for constraint...——这其实常是字符集不匹配导致索引无法隐式匹配。
用 LOAD DATA INFILE 导入时外键不触发检查，但有隐性风险
LOAD DATA INFILE 默认跳过外键约束检查（即使 FOREIGN_KEY_CHECKS = 1），这是它的设计行为。好处是导入快，坏处是脏数据悄无声息入库。比如子表导入了 user_id = 999，但主表根本没有这条记录，约束不会拦，后期查不到关联数据才暴露问题。因此建议：仅在确认数据已按父子顺序分批导入（先主表，再子表），且已用 SELECT ... FROM child LEFT JOIN parent ON ... WHERE parent.id IS NULL 校验过参照完整性后，才用此方式。否则宁可多花几秒，用 INSERT INTO ... SELECT 配合事务控制，至少能捕获第一波异常。
