应手动在SQL文件开头添加SET FOREIGN_KEY_CHECKS = 0;，结尾添加SET FOREIGN_KEY_CHECKS = 1;，或用mysql命令行预执行该语句；因DISABLE KEYS对InnoDB无效，且mysqldump默认不关闭外键检查，仅依赖表导出顺序，一旦文件被修改或目标库已有数据即易报错。
恢复数据时提示 Cannot add or update a child row: a foreign key constraint fails
这是 MySQL 导入 SQL 文件（尤其是 mysqldump 生成的）时最典型的外键报错。根本原因不是数据本身有问题，而是导入顺序破坏了父子表依赖关系——比如先插入子表记录，父表还没建好。DISABLE KEYS 对 InnoDB 表完全无效，它只作用于 MyISAM 的非唯一索引，别被名字误导。
真正该关的是外键检查开关：FOREIGN_KEY_CHECKS。但必须注意：它不能在单条 INSERT 语句里关，得在会话级或 SQL 文件头部统一控制。
- 导出时加
--skip-foreign-key-checks参数（mysqldump 不支持，别信网上乱传的） - 正确做法是手动在 SQL 文件开头加
SET FOREIGN_KEY_CHECKS = 0;，结尾加SET FOREIGN_KEY_CHECKS = 1; - 如果用 mysql 命令行导入，可以加
-e "SET FOREIGN_KEY_CHECKS=0;"预执行，但更稳妥的是改 SQL 文件本身
mysqldump 导出的 SQL 文件为什么默认不关外键检查
因为 mysqldump 默认按表结构顺序 dump，且对每个表内部保证 INSERT 顺序（先 dump 父表再子表），理论上能绕过外键冲突。但一旦你手动删改过 SQL 文件、或用了 --tab 分离数据与结构、或目标库已有部分数据，这个前提就崩了。
mysqldump --no-create-info 或 --ignore-table 后再导入，极易触发外键失败——因为你只导了子表数据，父表结构或数据缺失。
- 检查 dump 文件开头有没有
SET FOREIGN_KEY_CHECKS = 0;，没有就自己加 - 如果文件很大，别用文本编辑器硬开，用
sed -i '1s/^/SET FOREIGN_KEY_CHECKS = 0;\n/' backup.sql快速注入 - 导入完务必验证
SELECT @@FOREIGN_KEY_CHECKS;是否已恢复为 1，否则后续写操作可能静默失败
SET FOREIGN_KEY_CHECKS = 0 之后还要注意什么
关掉外键检查不等于数据就安全了。InnoDB 仍会校验主键、唯一索引、字段类型和 NOT NULL 约束，只是跳过外键关联逻辑。而且这个设置是会话级的，每个新连接都要单独设。
常见翻车点：用 GUI 工具（如 DBeaver、Navicat）导入时，工具可能自动开启新连接执行每批语句，导致 SET FOREIGN_KEY_CHECKS = 0 只在第一个连接生效，后面全报错。
- 用命令行导入最稳：
mysql -u root -p database_name - 避免在存储过程中动态 SET，函数内设了也只对当前语句有效
- 如果导入中途失败，记得手动执行
SET FOREIGN_KEY_CHECKS = 1;，否则后续所有操作都处于“裸奔”状态
DISABLE KEYS 到底有什么用，为什么有人误以为它能关外键
DISABLE KEYS 是 MyISAM 引擎的优化指令，作用是暂停非唯一索引的更新，等批量 INSERT 完再重建，大幅加速导入。但它对 InnoDB 完全无意义——InnoDB 没有这个机制，也不认这句 SQL。
很多人看到 mysqldump 输出里有 /*!40000 ALTER TABLE `table_name` DISABLE KEYS */; 就以为这是“关约束”的通用开关，其实这只是条件注释（MySQL 4.0.0+ 才执行），且仅对 MyISAM 生效。
- InnoDB 表遇到
DISABLE KEYS会直接忽略，不报错也不起效 - 如果表引擎混用（部分 MyISAM、部分 InnoDB），
DISABLE KEYS只加速 MyISAM 表，对 InnoDB 外键问题毫无帮助 - 想确认引擎类型，查
SHOW CREATE TABLE table_name;看末尾的ENGINE=InnoDB
SET FOREIGN_KEY_CHECKS = 0; 和 SET FOREIGN_KEY_CHECKS = 1; 当作 SQL 文件的固定包络线，而不是依赖工具或临时命令。 
