INSERT INTO ... SELECT 是嵌套子查询的标准写法，子查询必须置于 SELECT 部分作为数据源；VALUES 中不可嵌套子查询，否则语法错误；需确保列数、类型、顺序严格匹配，空结果不报错。
INSERT ... SELECT 里嵌套子查询的写法
直接用 INSERT INTO ... SELECT 就能完成，不需要额外的 VALUES 或临时表。核心是把子查询当做一个“虚拟结果集”塞进 SELECT 部分。
常见错误是试图在 VALUES 后面跟子查询——这会报错：ERROR: syntax error at or near "("，因为 VALUES 只接受字面值或参数，不支持子查询表达式。
- 子查询必须返回与目标列数量、类型兼容的字段；多列时用括号包裹整个子查询（如
(SELECT id FROM users WHERE active)），但仅限单列场景；多列请直接写在SELECT列表里 - 如果子查询可能返回空结果，整条
INSERT不会报错，只是不插入任何行——这是预期行为，不是 bug - 注意子查询里的
WHERE条件是否引用了外部表：若需要关联，得用JOIN或相关子查询（见下节）
带条件关联的子查询：EXISTS 还是 JOIN？
想“只插入 A 表中在 B 表存在匹配记录的那些行”，别硬套独立子查询。用 EXISTS 或 JOIN 更清晰、性能更好。
EXISTS 适合逻辑判断（“是否存在”），不关心具体值；JOIN 适合要取 B 表字段一起插入的场景。
- 用
EXISTS：INSERT INTO orders_archive (order_id, amount) SELECT o.order_id, o.amount FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'vip');
- 用
JOIN（更直观）：INSERT INTO orders_archive (order_id, amount, customer_name) SELECT o.order_id, o.amount, c.name FROM orders o JOIN customers c ON o.customer_id = c.id AND c.status = 'vip';
- 避免在
WHERE里写IN (SELECT ...)去匹配大表——可能全表扫描，尤其子查询无索引时；EXISTS或JOIN通常能走索引
子查询返回多行时的陷阱
如果子查询本意是查一个标量（比如某个配置值），但实际返回了多行，语句会直接失败：ERROR: more than one row returned by a subquery used as an expression。
- 这种错误常见于误把聚合函数漏掉，比如写成
SELECT (SELECT created_at FROM logs WHERE event='start')，而没加MAX()或LIMIT 1 - 修复方式取决于业务意图：要最新时间就加
MAX(created_at)；要任意一行就加LIMIT 1（但需确认是否可接受不确定性） - 不能依赖数据库自动截断——PostgreSQL 和 MySQL 都严格报错，SQL Server 默认也报错（除非兼容模式）
MySQL 和 PostgreSQL 的细微差异
语法主体一致，但细节上容易踩坑：
- MySQL 允许在
INSERT ... SELECT中对目标表和源表使用相同别名（如都叫t），PostgreSQL 不允许——会提示table name "t" specified more than once - PostgreSQL 要求子查询列名明确，如果子查询用了表达式（如
price * 1.1），最好显式AS new_price，否则目标列可能因列名缺失报错 - MySQL 5.7+ 默认开启
STRICT_TRANS_TABLES，如果子查询返回 NULL 而目标列是NOT NULL，会拒绝插入；PostgreSQL 同样校验，但错误信息更直白：null value in column "xxx" violates not-null constraint
跨数据库迁移这类语句前，先检查子查询是否隐含 NULL 或类型隐式转换——比如把字符串字段直接塞进数字列，MySQL 可能转成 0，PostgreSQL 直接报错。
