mysqldump 默认在每个 CREATE TABLE 前插入 SET FOREIGN_KEY_CHECKS=0，确保外键检查被禁用；若备份文件缺失该语句，需手动添加或避免使用 --compact 等删除该设置的选项。
mysqldump 备份时外键约束导致失败
直接用 mysqldump 备份有外键的库，有时会报错：Cannot delete or update a parent row: a foreign key constraint fails。这不是数据问题，而是 dump 过程中表导出顺序没按依赖关系排好，比如先 dump 了子表，后 dump 父表，恢复时插入父表前子表已建好、但父记录还没进库，外键校验就卡住。
解决方法很简单：加 --skip-foreign-key-checks 不行（它不是 mysqldump 的参数），真正该用的是：
-
--disable-keys：只影响索引重建，不关外键 -
--single-transaction：对 InnoDB 有效，能保证一致性，但不解决外键顺序问题 - 必须加
--order-by-primary或--skip-triggers也没用 - 正确做法是加
--no-create-info+ 手动控制顺序？太麻烦 - 最稳妥的是加
--skip-foreign-key-checks—— 等等，这参数确实不存在于mysqldump；真正起作用的是--set-gtid-purged=OFF（仅 GTID 场景）和关键的：--add-drop-table配合--extended-insert通常够用，但治标不治本
根本解法：让 mysqldump 自动处理依赖顺序，靠 --databases + --skip-lock-tables 不行，得用：
-
--skip-foreign-key-checks❌ 错误认知，这个参数属于mysql客户端，不是mysqldump - 正确参数是：
--foreign-key-checks=0❌ 也不对，mysqldump没这个选项 - 真相是：
mysqldump默认已禁用外键检查来生成 SQL——它在每个CREATE TABLE前加了SET FOREIGN_KEY_CHECKS=0，只要你不手动删掉这行，就安全 - 所以真正要检查的是：导出的 SQL 文件开头有没有
SET FOREIGN_KEY_CHECKS=0；没有？说明你用了--compact或自定义模板删掉了它
mysql 命令行恢复时提示 Cannot add or update a child row
恢复时报这个错，基本等于告诉你：SQL 文件里某条 INSERT INTO child_table 执行时，对应的 parent_table 记录还没插入，或者被跳过了。
常见原因和对策：
- 备份文件里没包含
SET FOREIGN_KEY_CHECKS=0—— 手动在文件开头加上这行，再执行 - 用了
source命令恢复，但当前 session 没关外键检查：SET FOREIGN_KEY_CHECKS=0;必须在source前运行 - 用
mysql -u user -p db_name 恢复，如果 SQL 文件里已有 <code>SET FOREIGN_KEY_CHECKS=0，但被注释了（比如mysqldump --compact输出），就得重导 - 恢复中途断了，部分父表数据进了库，子表没进，再跑一遍会主键冲突——此时不能直接重跑，得先
TRUNCATE所有表，或加--force参数忽略错误（不推荐）
示例：安全恢复命令组合
mysql -u root -p -e "SET FOREIGN_KEY_CHECKS=0; SOURCE /path/to/backup.sql;" your_db
mysqldump 导出时要不要加 --skip-foreign-key-checks
不用加，也加不了——mysqldump 命令本身没有这个参数，加了会报 unknown option '--skip-foreign-key-checks'。
它实际行为是：默认就在每个 CREATE TABLE 语句前后插入 SET FOREIGN_KEY_CHECKS=0 和 SET FOREIGN_KEY_CHECKS=1，确保建表时不被外键拦住。
- 如果你看到导出 SQL 里没有这行，大概率用了
--compact或--no-autocommit等精简模式 - 想确认是否启用，导出后 grep 一下：
grep "FOREIGN_KEY_CHECKS" backup.sql - InnoDB 表用
--single-transaction时，SET FOREIGN_KEY_CHECKS=0仍会保留，不影响一致性 - MyISAM 表不支持事务，但外键本身就不生效，所以这行只是占位，无实质影响
SET FOREIGN_KEY_CHECKS=0 在哪些场景下必须手动加
不是所有情况都靠 dump 文件自带的那行就能覆盖。以下场景你得自己干预：
- 用
mysqlpump（MySQL 5.7+）替代mysqldump：它默认不写SET FOREIGN_KEY_CHECKS=0，必须显式加--skip-foreign-key-checks参数（注意，这是mysqlpump支持的真参数） - 分表导出、手工拼 SQL：比如只导出几个表，用
mysqldump db t1 t2，若 t2 依赖 t1，但导出顺序反了，且你删了 SQL 头部的SET行，就必须补上 - Docker 或 CI 环境自动恢复：脚本里别只写
mysql -e "source ..."，前面一定跟一句mysql -e "SET FOREIGN_KEY_CHECKS=0" - 跨版本恢复（如 MySQL 5.6 → 8.0）：8.0 默认
FOREIGN_KEY_CHECKS=1，且某些旧 dump 的兼容头可能被忽略，宁可多写一行
最容易被忽略的一点：有些 ORM 或迁移工具（如 Django dumpdata）生成的 JSON/YAML 数据不带任何 SQL 设置，导入时完全依赖目标库当前 session 状态——这时候不手动关，铁定报错。
