mysqldump导出不校验外键，报错只发生在导入阶段；导出文件须含SET FOREIGN_KEY_CHECKS=0，或导入前手动执行该命令并配对恢复为1，否则外键约束失效可能导致数据不一致。
不能靠“绕过”导出数据——mysqldump 本身不校验外键，所谓“绕过”是误解；真正要处理的是导入时的约束拦截，而导出阶段只需确保生成的 sql 文件自带 set foreign_key_checks=0。
mysqldump 导出时根本不会触发外键报错
很多人以为导出报 Cannot add or update a child row 是因为外键拦住了 mysqldump，其实不是。mysqldump 只读数据、不写数据，它不执行 INSERT，也不做外键校验。那个错误只会在 导入 阶段出现。
导出失败的真实原因通常是：
- 表被锁住（尤其 MyISAM 或未加 --single-transaction 的 InnoDB）
- 权限不足（比如没 SELECT 权限）
- 触发器或存储过程里有非法逻辑（非外键问题）
所以别在导出命令里加 --skip-foreign-key-checks——这个参数根本不存在于 mysqldump，加了会被忽略。
导出文件必须含 SET FOREIGN_KEY_CHECKS=0 才安全
mysqldump 默认会在每个 CREATE TABLE 语句前插入 SET FOREIGN_KEY_CHECKS=0，但以下情况会丢失它：
- 使用了 --compact（精简模式，删所有注释和设置语句）
- 用了自定义 --templates 或管道过滤掉了 SET 行
- 用 --no-create-info 后手动拼接结构文件，忘了补这句
检查方法：导出后直接 head -n 20 mydb.sql | grep FOREIGN_KEY，确认有 SET FOREIGN_KEY_CHECKS=0。
没有？重导，去掉 --compact，或手动在文件开头加上这一行。
导入前手动关检查比依赖 dump 文件更可靠
即使 dump 文件里有 SET FOREIGN_KEY_CHECKS=0，也存在失效风险：
- 目标 MySQL 版本 ≥ 8.0.29 且启用了 require_row_format
- 用 GUI 工具（如 DBeaver）分批执行，每批新建会话，SET 不继承
- 文件被编辑过，SET 行被意外删掉或注释
最稳做法：
- 先连库：mysql -u root -p mydb
- 手动执行：SET FOREIGN_KEY_CHECKS=0;
- 再执行：source /path/to/mydb.sql
- 导入完立刻：SET FOREIGN_KEY_CHECKS=1; 并运行 CHECK TABLE orders, users;
别信“关了外键就啥都不拦”这种说法
SET FOREIGN_KEY_CHECKS=0 只停外键校验，其他约束照常生效：
- 主键重复仍报 Duplicate entry '1' for key 'PRIMARY'
- 唯一键冲突照样卡住
- NOT NULL 字段插 NULL 还是失败
- 字符集/排序规则不匹配导致建表失败（如 utf8mb4 vs utf8）
如果导入中途报主键冲突，不是外键问题，而是：
- 目标库已有旧数据，该清没清（用 TRUNCATE TABLE，别用 DELETE FROM）
- dump 文件里混了两次导出的数据（检查 INSERT INTO 是否重复）
- 源库和目标库自增起始值不同，手动设过 AUTO_INCREMENT 却没同步
真正容易被忽略的点是：关了外键之后，没人帮你兜底。数据引用关系断了，你得自己查 information_schema.KEY_COLUMN_USAGE 和抽样 JOIN 验证，而不是等着报错才发觉。
