应先导入主表并构建ID映射字典，再将子表外键字段（如姓名）映射为真实ID，对映射失败值设为NaN以暴露数据问题；LOAD DATA不支持动态映射，需预处理CSV；外键缺失反映主数据不一致，须前置核验。
外键约束导致导入失败：直接关掉它不解决问题
导入 csv 时遇到 cannot add or update a child row: a foreign key constraint fails，第一反应是关掉外键检查——但关了之后数据进去了，外键列全是 null 或非法值，表关系就废了。这不是“临时绕过”，而是把问题藏起来等后续爆雷。
- MySQL 中用
SET FOREIGN_KEY_CHECKS = 0确实能跳过校验，但仅适用于你**已确认所有外键值在目标表中存在**，只是导入顺序不对（比如先导order表、后导customer表） - 如果 CSV 里本来就有缺失的外键（例如
customer_id=9999，但数据库里根本没有这个客户），关检查只会让脏数据落库，后续连JOIN都查不出结果 - PostgreSQL 没有全局开关，必须用
NOT VALID方式添加约束再手动验证，操作成本更高
先导入主表，再用映射字典补全外键 ID
真正稳妥的做法是分两步：先把所有主表（如 users、products）导入完毕，生成一份内存映射字典，再处理子表 CSV 中的外键字段（如姓名、编码、邮箱等可识别字段），转成真实 ID。
- 别依赖 CSV 原始的
user_name直接写入外键列；应先用pandas.read_csv()读入，再通过pd.merge()或map()关联主表 ID - 示例：子表 CSV 有列
sales_rep_name，主表staff有name和id；用df_sub['sales_rep_id'] = df_sub['sales_rep_name'].map(name_to_id_dict) - 对映射不到的值，显式设为
NaN，而不是留空或塞默认值——这样你能立刻发现哪些记录缺少上游数据
LOAD DATA INFILE 无法做映射？那就别硬上
MySQL 的 LOAD DATA INFILE 极快，但它不支持表达式、函数或跨表查询，碰到需要把 CSV 里的 “部门名称” 转成 “部门ID” 这类需求，硬套会直接失败或写错值。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
-
SET department_id = (SELECT id FROM departments WHERE name = @department_name)在LOAD DATA中不被允许 - 若坚持用
LOAD DATA，必须提前把 CSV 外键列替换成 ID —— 用 Python/Pandas 处理完再保存新 CSV，再导入 - 大批量场景下，可导出主表为
id,name的 CSV，用awk或csvsql做左连接，比纯 Python 更快，但可读性下降
外键缺失不是技术问题，是数据治理信号
反复出现 “找不到 customer_id=12345” 这类报错，说明你的 CSV 来源系统和目标数据库之间存在主数据不一致。这不是脚本该兜底的事。
- 上线前必须核对关键主表记录数、ID 范围、业务唯一键（如手机号、订单号）是否全覆盖
- 在导入脚本里加一道检查：统计映射失败行数，若超过阈值（如 > 0.1%），直接中断并输出前 10 行样例，而不是默默填
NULL - 临时补数据可以跑
INSERT ... SELECT，但得确保来源字段语义对齐——比如用email匹配，就得确认两边 email 都 trim 过、大小写一致、无重复
外键不是锁，是契约。假装它不存在，契约就失效了。
