不能直接用JOIN做插入校验，因为JOIN是查询语义，INSERT...VALUES语法不支持JOIN，会报错；正确做法是用INSERT...SELECT结合LEFT JOIN或EXISTS子查询实现校验后插入。
为什么不能直接用 JOIN 做插入校验
JOIN 是查询语义，不是数据修改操作。SQL 标准中 INSERT ... SELECT 可以结合 JOIN 检查主从关系是否存在，但 INSERT ... VALUES 本身不支持 JOIN；试图在 INSERT 语句里写 JOIN 会直接报错：ERROR: syntax error at or near "JOIN"。真正要“校验后插入”，本质是把约束逻辑从应用层下沉到 SQL 层，靠原子性 + 子查询或连接查询实现。
用 INSERT ... SELECT + LEFT JOIN 拦住非法从记录
典型场景：向订单明细表 order_items 插入前，确保其 order_id 在 orders 表中存在。不能靠外键（比如临时禁用、或表没建 FK），就得手动校验。
- 写法核心是：把待插数据当“源”，LEFT JOIN 主表，WHERE 主表 ID 为 NULL 则说明不合法
- 示例（PostgreSQL/MySQL 8.0+）：
INSERT INTO order_items (order_id, product_id, qty) SELECT t.order_id, t.product_id, t.qty FROM (VALUES (1001, 'P001', 2), (1002, 'P002', 1)) AS t(order_id, product_id, qty) LEFT JOIN orders o ON o.id = t.order_id WHERE o.id IS NOT NULL;
这条语句只会插入那些 order_id 真实存在的行；WHERE o.id IS NOT NULL 过滤掉了非法关联。注意：MySQL 5.7 不支持 VALUES 表达式直接用于 FROM，得改用 SELECT ... UNION ALL 模拟。
用 EXISTS 替代 JOIN 实现更清晰的语义
当只关心“主记录是否存在”，不需获取主表字段时，EXISTS 比 JOIN 更轻量、意图更明确，且避免因主表多行导致的笛卡尔积放大问题。
- 同样插入
order_items，但校验逻辑内联在子查询中： -
EXISTS子查询不返回数据，只返回布尔结果，优化器更容易短路 - 对主表有唯一索引（如
PRIMARY KEY或UNIQUE）时，性能几乎无损
INSERT INTO order_items (order_id, product_id, qty) SELECT t.order_id, t.product_id, t.qty FROM (VALUES (1001, 'P001', 2), (1002, 'P002', 1)) AS t(order_id, product_id, qty) WHERE EXISTS (SELECT 1 FROM orders WHERE id = t.order_id);
批量插入失败时如何拿到具体哪一行被拒绝
上面两种写法都“静默丢弃”非法行，不报错也不返回信息。如果业务要求明确反馈（比如告诉前端“第3条 order_id=9999 不存在”），纯 SQL 很难做到——因为标准 INSERT 不支持 RETURNING 配合条件过滤后的原始输入行号。
- PostgreSQL 可用
WITH+UNION ALL构造带序号的临时数据集，再 LEFT JOIN 后筛选出o.id IS NULL的行并 RETURNING - 但更现实的做法是：先用
SELECT做预检，把不合法的order_id提前捞出来，再决定是否继续插入 - 例如：
SELECT t.order_id FROM (VALUES ...) AS t(...) LEFT JOIN orders o ON o.id = t.order_id WHERE o.id IS NULL
这个预检查询本身就能告诉你哪些值不合法，比在 INSERT 里硬塞校验逻辑更可控。别为了“一条 SQL 完成”牺牲可读性和调试成本。
