mysqldump 外键报错因默认按表名排序导出，不满足依赖顺序；应使用 --databases + --single-transaction（InnoDB）自动逆序导出，或导出时加 --skip-foreign-key-checks 使 dump 文件含 SET FOREIGN_KEY_CHECKS=0;，导入时配合 --init-command="SET FOREIGN_KEY_CHECKS=0;" 确保全程生效。
导出时外键约束导致 mysqldump 报错：Cannot add or update a child row
这不是数据问题，而是 mysqldump 默认按表名字母序导出，不考虑外键依赖关系。比如 orders 表依赖 users，但 orders.sql 被先导入，而 users 还没建好或没插数据，就会触发该错误。
解决办法不是手动调顺序，而是让 mysqldump 自动处理依赖：
- 加
--order-by-primary保证主键有序插入（对单表有效，但不解决跨表依赖） - 必须加
--skip-foreign-key-checks—— 注意：这是导出时的选项，它会让 dump 文件开头写入SET FOREIGN_KEY_CHECKS=0;，导入时才生效 - 更稳妥的是用
--databases+--single-transaction（InnoDB），它会自动按外键依赖逆序导出：先导被引用的表（如users），再导引用它的表（如orders）
导入时禁用外键检查的两种写法，效果完全不同
SET FOREIGN_KEY_CHECKS=0; 必须在每个 SQL 语句前生效，不是“设一次管全程”。常见错误是只在文件开头写一次，结果中间某条 INSERT 仍被拦住。
正确做法分两种场景：
- 用
mysql命令行导入：mysql -u root -p --init-command="SET FOREIGN_KEY_CHECKS=0;" db_name - 修改 dump 文件本身：确保每段
INSERT前都有SET FOREIGN_KEY_CHECKS=0;，或把整个文件包裹在BEGIN; ... COMMIT;中（仅限事务安全引擎） - 别用
source在 MySQL 客户端里执行 dump 文件——它不继承--init-command，且客户端默认不会重置会话变量
临时关约束后，唯一索引/主键冲突被忽略？不是，是报错转移了
关掉 FOREIGN_KEY_CHECKS 只影响外键校验，不影响 UNIQUE、PRIMARY KEY 或 NOT NULL 约束。很多人以为“关了约束就啥都不拦”，结果导入时卡在 Duplicate entry '1' for key 'PRIMARY'。
这时候要判断：是重复数据（需去重），还是目标库已有旧数据（应先清空）？
- 清空表用
TRUNCATE TABLE，比DELETE FROM更快，且会重置自增计数器 - 如果只是补数据，用
INSERT IGNORE或ON DUPLICATE KEY UPDATE，但这些必须改写 dump 文件里的INSERT语句，不能靠开关变量实现 -
mysqldump默认生成INSERT，不是REPLACE；加--replace参数才能生成REPLACE INTO语句
迁移后忘记开外键检查，后续写操作可能静默失败
FOREIGN_KEY_CHECKS 是会话级变量，默认值为 1，但你用 --init-command 或手动 SET 关掉后，这个会话里它就一直是 0，直到连接断开。新连接不受影响。
所以真正危险的是：你用同一个 MySQL 客户端连接，导入完没手动 SET FOREIGN_KEY_CHECKS=1;，接着又手写 INSERT 或跑脚本，外键失效却无提示，脏数据就这么进去了。
- 检查当前状态用：
SELECT @@FOREIGN_KEY_CHECKS; - 生产环境迁移脚本末尾务必加上：
SET FOREIGN_KEY_CHECKS=1; - 如果用 ORM 或应用层连库，每个连接都是独立会话，不用额外处理；但 DBA 直连操作后一定要重置
