子查询在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 阶段触发。两者不等价，漏掉约束仍会报错。