外键约束下导入数据报错“Cannot add or update a child row”是因为子表插入时父表主键尚未存在，MySQL默认实时校验外键有效性，必须先导入父表再导入子表，且需注意ID映射一致性与禁用检查的风险。
外键约束下导入数据时为什么报错 Cannot add or update a child row
因为数据库在插入子表记录时，对应的父表主键还没存在。mysql（以及多数关系型数据库）默认开启外键检查，insert 语句会实时校验外键引用是否有效——不是等全部导入完再统一检查。
- 必须先导入父表（如
users），再导入子表（如orders），顺序不能颠倒 - 如果用
mysqldump导出，确认它用了--skip-extended-insert或按表分块导出，否则单条超长INSERT可能混入未就绪的 ID - CSV 导入时别依赖自增 ID 的“预期值”，比如手动写死
user_id = 1001却没验证该 ID 是否已存在于目标库
如何临时禁用外键检查来绕过顺序问题
可以关掉 FOREIGN_KEY_CHECKS，但这是权宜之计，不是设计补救——关了之后导入错误数据也不会报错，后期查起来更麻烦。
- 执行
SET FOREIGN_KEY_CHECKS = 0;后再导入，完事必须立刻执行SET FOREIGN_KEY_CHECKS = 1; - 仅限一次性迁移或测试环境；生产环境禁用后没及时恢复，后续正常业务写入可能悄悄破坏完整性
- PostgreSQL 没有全局开关，得用
SET CONSTRAINTS ALL DEFERRED配合事务，且只对DEFERRABLE约束生效（建表时就得声明）
LOAD DATA INFILE 和 INSERT ... SELECT 对外键的处理差异
两者都受外键约束实时校验，但失败行为不同：前者整批失败并回滚，后者默认是单行失败（取决于 SQL mode）。
-
LOAD DATA INFILE遇到第一处外键不匹配就中断，不会跳过坏行——除非加IGNORE，但IGNORE会静默丢弃整行，连警告都不留 -
INSERT ... SELECT在严格模式下也会停在第一错，但配合ON DUPLICATE KEY UPDATE或INSERT IGNORE可实现部分容错（注意：这不解决外键缺失，只缓解唯一键冲突） - 用
INSERT ... SELECT从同库另一张结构相同但无外键的临时表导入，可规避校验（前提是临时表数据本身逻辑正确）
级联导入时 ID 映射错位的真实风险
当源库和目标库主键不一致（比如目标库已有数据、ID 从 10000 起步），直接复制外键值会导致指向错误记录，甚至跨用户关联。
- 别用脚本全局替换 CSV 里的数字 ID；应建立映射表，例如
old_user_id → new_user_id，导入子表前查表转换 - 如果源库用 UUID 做主键，目标库也必须保持一致；混合使用自增 ID 和 UUID 容易在关联字段类型不匹配时报
Data truncated for column - PostgreSQL 的
serial类型在COPY时若未显式指定列，可能把传入的 ID 当作默认值跳过，导致新生成 ID——务必写全字段名
最麻烦的不是插不进去，而是插进去了但关联错了。这种错误上线后很难追溯，尤其当业务逻辑依赖多层嵌套外键时，一个 ID 映射偏差会引发下游数张表的数据语义错乱。
