子查询不能直接塞入INSERT INTO的VALUES列表，必须置于SELECT子句中作为数据源；若在字段列表中返回多行，MySQL报“Subquery returns more than 1 row”错误。
INSERT INTO SELECT 里子查询写在哪一层
子查询不能直接塞进 INSERT INTO 的 VALUES 列表里，必须放在 SELECT 子句中——也就是作为数据源那一侧。常见错误是写成 INSERT INTO t2 VALUES (SELECT id FROM t1 WHERE ...)，这在绝大多数 SQL 引擎里会报语法错。
正确结构只有两种：要么整个 SELECT 是子查询（比如 INSERT INTO t2 SELECT * FROM (SELECT ...) AS tmp），要么子查询嵌在 SELECT 的字段或 WHERE 条件里。
-
INSERT INTO t2(col1, col2) SELECT (SELECT max(id) FROM t1), name FROM t3—— 子查询当表达式用，返回单值 -
INSERT INTO t2(col1, col2) SELECT id, name FROM t3 WHERE id IN (SELECT id FROM t1 WHERE status = 'active')—— 子查询在 WHERE 中过滤 - 跨库迁移时，
SELECT源表名要带库名前缀，如source_db.users，MySQL 需用反引号、PostgreSQL 用双引号、SQL Server 用方括号
子查询返回多行时 INSERT 会报什么错
当子查询被当作标量表达式使用（即出现在字段列表里），但实际返回多于一行，数据库会立刻报错，错误信息类似：Subquery returns more than 1 row（MySQL）或 more than one row returned by a subquery used as an expression（PostgreSQL）。
这不是数据类型不匹配，而是语义冲突：一个字段位置只能填一个值。
- 想让多行结果“展开”到多条记录里？那就别把它塞进字段列表，改用
SELECT主体直接查那张表 - 真需要聚合后插入？加
MAX()、COUNT()或GROUP BY确保单行输出 - 用
EXISTS替代IN可避免部分引擎对子查询行数的校验开销，尤其在大表关联时
INSERT INTO SELECT 带子查询时的性能坑点
子查询本身不慢，慢在它打断了优化器对整条语句的执行计划推导。特别是 WHERE ... IN (SELECT ...) 这种写法，MySQL 5.7+ 会默认转成 DEPENDENT SUBQUERY，导致外层每行都重跑一次子查询。
更糟的是，如果子查询没走索引，又没加 LIMIT，可能全表扫两次。
- 把
IN (SELECT ...)改成JOIN，例如INSERT INTO t2 SELECT t1.* FROM t1 JOIN t3 ON t1.id = t3.ref_id WHERE t3.status = 'done' - 确保子查询里的关联字段（如
t3.ref_id）有索引，EXPLAIN看type列是不是ref或eq_ref - 分批插入千万级数据时，别用
WHERE created_at > '2025-01-01'这类时间范围，改用WHERE id > last_processed_id，避免因时钟漂移或重复写入漏数据
跨库迁移时子查询字段名冲突怎么处理
当 SELECT 里混用多个库的表，又用了 * 或未加别名的字段，很容易触发 Column 'id' in field list is ambiguous 错误——因为两个库的表都有 id 字段，SQL 引擎不知道你要哪个。
这不是语法问题，是标识符解析歧义。
- 永远不用
SELECT *在跨库INSERT INTO SELECT场景里，显式列出所有目标字段并加表别名，如t1.id, t1.name, t2.extra - MySQL 中库名和表名之间用点号连接，但库名本身含下划线或特殊字符时，必须用反引号包裹，例如
`db_kingform_dev`.users - PostgreSQL 对大小写敏感，若目标表字段是小写而子查询返回大写别名，需用双引号强制匹配：
SELECT u."id", u."name" FROM source.users u
子查询嵌得越深，执行计划越难预测；真正卡住的往往不是语法对不对，而是优化器有没有把 JOIN 条件推下去、索引有没有被真正用上。上线前务必在测试库跑 EXPLAIN，盯着 rows 和 Extra 列看。
