必须关闭外键约束再导入数据，否则因依赖顺序问题导致INSERT失败；MySQL需SET FOREIGN_KEY_CHECKS=0，PostgreSQL则需SET CONSTRAINTS DEFERRED或禁用触发器。
导入前必须关掉外键约束，否则 INSERT 直接报错
mysql 默认开启外键检查（foreign_key_checks=1），一旦目标表有外键依赖，而被引用的父记录还没插入，insert 就会立刻失败，报错类似：cannot add or update a child row: a foreign key constraint fails。这不是数据问题，是执行顺序被约束卡住了。
实操建议：
- 导入前执行
SET FOREIGN_KEY_CHECKS = 0;，临时关闭检查 - 确保所有相关表（父表、子表）都按依赖顺序导入：先父后子
- 不要在事务外单独关检查再手动开——容易遗漏或出错
- 如果用
mysqldump导出，加--skip-foreign-key-checks参数可自动生成关闭语句
SET FOREIGN_KEY_CHECKS = 1 不等于自动校验历史数据
重新开启外键检查后，MySQL **不会**回扫已有数据去验证一致性。它只对后续的 INSERT、UPDATE、DELETE 生效。也就是说，导入时绕过检查写进去的“脏数据”，只要没被修改，就一直安静躺着，不报错也不提醒。
实操建议：
- 开启检查后，必须主动触发一次校验：对每个带外键的子表执行
SELECT查询，显式关联父表，例如SELECT * FROM child WHERE parent_id NOT IN (SELECT id FROM parent) - 更稳妥的做法是用
ALTER TABLE ... ENGINE=InnoDB重建表——InnoDB 会在重建时强制校验外键完整性，失败则中止 - 注意：重建大表会锁表、耗时长，生产环境慎用
用 LOAD DATA INFILE 导入时，外键检查状态取决于会话而非全局
很多人以为设了全局变量就一劳永逸，但 LOAD DATA INFILE 是在当前会话里执行的，只认该会话的 FOREIGN_KEY_CHECKS 值。如果脚本里没显式设置，哪怕全局是 0，也可能因连接复用或会话隔离导致实际为 1。
实操建议：
- 在执行
LOAD DATA INFILE前，务必在同一会话内执行SET FOREIGN_KEY_CHECKS = 0; - 避免把
SET和LOAD拆到两个不同脚本或连接中 - 用客户端工具（如 MySQL Workbench）执行时，确认“按执行顺序单个会话运行”，别勾选“每个语句新开会话”
- 导入完成后，用
SELECT @@FOREIGN_KEY_CHECKS;确认当前值确实是 1
PostgreSQL 没有 FOREIGN_KEY_CHECKS 开关，得换思路
PostgreSQL 不提供运行时开关，外键约束始终生效。想跳过校验，只能临时禁用约束本身：ALTER TABLE child_table DISABLE TRIGGER ALL;。但这不是等价替代——它禁的是所有触发器，包括自定义逻辑，风险更高。
实操建议：
- 优先用
SET CONSTRAINTS ALL DEFERRED+ 事务包裹导入，让外键检查延迟到COMMIT时统一做 - 禁用触发器后，必须手动确保父表数据已存在，且
COMMIT前重新启用：ALTER TABLE child_table ENABLE TRIGGER ALL; - 禁用操作需
superuser权限，普通应用账号通常做不到，这点比 MySQL 更受限
外键校验不是开关一按就完事的事。真正麻烦的是：关的时候怕漏依赖，开之后又不报旧账，查起来得自己写 SQL 挖；跨数据库时连开关都没有，还得翻文档找替代路径。这些地方，不跑一遍真实数据，光看文档根本意识不到。
