应临时关闭外键检查：先查状态select @@foreign_key_checks，再set foreign_key_checks = 0执行恢复，完成后立即set foreign_key_checks = 1；注意该变量为会话级，需手动恢复且不校验历史数据，恢复后须手动查孤儿记录并清理。
恢复时提示 Cannot add or update a child row: a foreign key constraint fails 怎么办
这是 MySQL 导入或执行 INSERT/UPDATE 时最典型的外键冲突报错，本质是数据插入顺序不满足父子表依赖关系——比如先插子表记录，但父表对应主键还没写入。临时关闭约束检查是最直接的绕过方式，但必须清楚它只影响检查时机，不解除约束定义本身。
怎么安全地临时关闭 foreign_key_checks
关键不是“关”，而是“关在哪、何时开、会不会漏”。MySQL 的 foreign_key_checks 是会话级变量，只对当前连接生效，不影响其他客户端。操作前务必确认你在目标数据库连接里执行：
- 先查当前状态：
SELECT @@foreign_key_checks;（返回 1 表示开启） - 临时关闭：
SET FOREIGN_KEY_CHECKS = 0; - 执行你的恢复操作（如
SOURCE backup.sql或批量INSERT） - 立即恢复检查：
SET FOREIGN_KEY_CHECKS = 1;（别依赖自动恢复，会话断开就失效）
注意：不能在存储过程或函数里用 SET FOREIGN_KEY_CHECKS = 0 来绕过校验——它会被忽略，且可能触发警告。
mysqldump 导出时没加 --skip-extended-insert 会导致恢复失败？
不会直接导致外键报错，但会影响恢复时的错误定位。默认 mysqldump 用 INSERT ... VALUES (...), (...), (...) 批量插入，一旦某一行违反外键，整条语句回滚，你只能看到“第 X 行失败”，却不知道具体哪条值出问题。加上 --skip-extended-insert 后每行独立 INSERT，出错时能准确定位到单条记录，方便人工修正或跳过。
更稳妥的做法是导出时就禁用外键检查：mysqldump --no-create-info --skip-triggers --skip-extended-insert --set-gtid-purged=OFF --databases mydb > backup.sql，然后在 SQL 文件开头手动加 SET FOREIGN_KEY_CHECKS = 0;，结尾加 SET FOREIGN_KEY_CHECKS = 1;。
foreign_key_checks = 0 期间做了脏数据，后续怎么补救
这是最容易被忽略的风险点：关掉检查后插入了孤儿记录（子表有值，父表无对应主键），后续即使重新打开 FOREIGN_KEY_CHECKS = 1，MySQL 也不会主动校验存量数据——它只校验新增/修改操作。所以恢复完成后必须手动验证：
- 查孤儿记录：
SELECT child.id FROM child LEFT JOIN parent ON child.parent_id = parent.id WHERE parent.id IS NULL; - 确认业务是否允许这些数据（比如测试环境可清空，生产环境需补父表或删子表）
- 必要时用
ALTER TABLE child DROP FOREIGN KEY fk_name;临时删约束再清理，完事再加回来
真正麻烦的不是关检查，而是关了之后没做数据一致性兜底——毕竟约束关了，责任没关。
