INSERT INTO ... SELECT 是将子查询结果插入目标表的最常用高效方式，必须确保列数、类型、顺序严格匹配，不可用 VALUES 包裹子查询；支持 JOIN、WHERE 等复杂查询，但空结果不报错，类型不匹配或约束冲突才会报错。
INSERT INTO ... SELECT 适合插入子查询结果
直接用 INSERT INTO ... SELECT 是最常用、最高效的方式，它把子查询当作数据源，一行行插入目标表。不能用 VALUES 语法配合子查询——那会报错 ERROR: subquery must return only one column 或类似提示。
常见错误是写成：INSERT INTO users VALUES (SELECT id, name FROM temp_users) —— 这在所有主流 SQL 引擎（PostgreSQL、MySQL、SQL Server）里都非法。
-
INSERT INTO target_table (col1, col2) SELECT col_a, col_b FROM source_table WHERE ...—— 列数、类型、顺序必须严格匹配 - 目标表字段列表可省略，但要求子查询列数与目标表结构完全一致（包括顺序），不推荐省略，易出错
- 子查询可以带
JOIN、WHERE、GROUP BY，甚至嵌套，只要最终返回二维结果集即可
MySQL 和 PostgreSQL 对 INSERT ... SELECT 的兼容性差异
基本语法一致，但细节上容易踩坑：
- MySQL 允许
INSERT IGNORE INTO ... SELECT或INSERT INTO ... SELECT ON DUPLICATE KEY UPDATE ...，PostgreSQL 需用INSERT ... SELECT ... ON CONFLICT DO UPDATE - PostgreSQL 要求子查询别名（如果用了
AS）不能和目标列名冲突；MySQL 更宽松 - SQL Server 同样支持
INSERT INTO ... SELECT，但不支持ON DUPLICATE KEY UPDATE，得用MERGE替代 - Oracle 需注意：若子查询含
ROWNUM或分析函数，可能影响结果一致性，建议先封装为 CTE 再插入
INSERT ... SELECT 性能和锁行为需要注意什么
这不是“轻量级操作”——它会按需加锁，且可能触发大量日志写入，尤其在大表间复制时。
- PostgreSQL 中，整个
SELECT阶段会持有ROW SHARE锁，目标表插入过程持ROW EXCLUSIVE锁；高并发下易阻塞 - MySQL（InnoDB）默认在语句级加锁，若子查询扫描全表，可能引发间隙锁（gap lock），拖慢其他事务
- 避免在生产高峰期执行跨大表的
INSERT ... SELECT；考虑分批：用LIMIT+OFFSET（MySQL）或FETCH FIRST n ROWS ONLY（PostgreSQL）控制批次大小 - 某些场景下，
CREATE TABLE AS SELECT比INSERT ... SELECT更快（无约束校验、无索引维护开销），但仅适用于新建表
子查询返回空结果时 INSERT 会不会报错
不会。空结果集只是不插入任何行，语句仍成功执行，rows affected 返回 0。这点常被误认为“没生效”，其实逻辑正确。
真正容易漏掉的是：子查询中字段类型隐式转换失败（比如把字符串往 INT 列插）、NULL 插入非空列、违反唯一约束——这些才会报错，且错误位置指向 INSERT 语句本身，不是子查询。
- 调试技巧：先把子查询单独运行一遍，确认返回结果的列名、类型、NULL 性是否符合目标表定义
- PostgreSQL 可用
\set VERBOSITY verbose查看更详细的错误上下文；MySQL 建议开启log_warnings = 2捕获隐式转换告警 - 若子查询含聚合（如
COUNT(*)），确保外部没有遗漏GROUP BY，否则可能只返回一行却试图插入多行目标结构中
