子查询在INSERT...SELECT中须用INSERT INTO...SELECT语法，不可用INSERT INTO...VALUES(SELECT...)；需列数类型匹配，MySQL引用目标表时须派生表包装，条件性靠WHERE筛选，防重用NOT EXISTS，注意事务隔离级与约束校验。
子查询在 INSERT ... SELECT 中的正确写法
直接用子查询实现条件性批量插入，核心是 INSERT INTO ... SELECT 语法，不是 INSERT INTO ... VALUES (SELECT ...) —— 后者在绝大多数数据库中会报错或语义不符。
常见错误现象：ERROR: syntax error at or near "SELECT"（PostgreSQL）、You can't specify target table for update in FROM clause（MySQL 5.7 及更早版本对同一表的子查询限制）。
- 必须确保子查询返回的列数、顺序、类型与目标表字段严格匹配（或显式指定目标字段）
- MySQL 中若子查询引用了待插入的目标表，需用派生表包装绕过限制：
SELECT * FROM (SELECT ... FROM t) AS tmp - PostgreSQL 和 SQL Server 支持在子查询中直接关联其他表做条件过滤，无需额外包装
用 WHERE 或 JOIN 实现“条件性”插入
“条件性”不靠 IF 或 CASE 控制是否插入整行，而是靠子查询的 WHERE 筛选结果集——没被选中的行自然不会插入。
典型场景：只把满足业务规则的新数据从日志表同步到主表，且避免重复（如按时间窗口 + 唯一标识去重）。
- 用
NOT EXISTS防重：INSERT INTO users SELECT ... FROM logs l WHERE NOT EXISTS (SELECT 1 FROM users u WHERE u.id = l.user_id) - 用
LEFT JOIN ... IS NULL效果等价，但可读性略差；部分数据库对NOT EXISTS优化更好 - 避免在
WHERE中使用不可索引的表达式（如UPPER(email)），否则全表扫描风险高
MySQL 中子查询不能直接引用目标表的绕过方法
MySQL 报错 You can't specify target table 't' for update in FROM clause 的本质是语法限制，不是逻辑问题。必须打破“同一语句中 FROM 和 INSERT 指向同一张表”的直觉写法。
- 最简方案：用派生表包装子查询，例如：
INSERT INTO t SELECT * FROM (SELECT a,b FROM t WHERE c > 100) AS tmp - 如果子查询含聚合或窗口函数，确保外层别名存在（MySQL 8.0+ 要求所有派生表必须有别名）
- 注意性能：派生表可能阻止某些优化器路径，大数据量时建议先用
CREATE TEMPORARY TABLE缓存中间结果
INSERT ... SELECT 的事务与并发安全要点
这类操作默认是一条语句，但“条件性”往往依赖子查询结果快照——它取决于事务隔离级别，不是实时状态。
- 在
READ COMMITTED下，子查询看到的是语句开始时已提交的数据；REPEATABLE READ（MySQL 默认）下看到的是事务开始时的快照 - 如果插入逻辑依赖外部状态（如“余额大于 0 才允许创建订单”），仅靠子查询无法保证强一致性，需配合
SELECT ... FOR UPDATE加锁 - 批量插入时，单次语句比循环执行
INSERT ... VALUES更高效，但也要留意锁升级和日志体积——超 10 万行建议分批次
真正容易被忽略的是：子查询里的条件判断和主表约束（比如唯一索引、外键）是两套校验机制，前者在 SELECT 阶段过滤，后者在 INSERT 阶段触发。两者不等价，漏掉约束仍会报错。
