INSERT INTO ... SELECT 是最常用且安全的嵌套子查询写法，直接在 INSERT INTO 后接 SELECT 语句，而非将 SELECT 嵌入 VALUES 中；后者在多数 SQL 方言中语法错误，仅 PostgreSQL 允许 (SELECT ...) 作为单值标量表达式，且须严格返回一行一列。
INSERT INTO ... SELECT 是最常用且安全的嵌套子查询写法
直接在 INSERT INTO 后面接 SELECT 语句，而不是用括号包裹子查询塞进 VALUES 里——后者在绝大多数 SQL 方言中语法错误。比如想把用户表中活跃用户的 ID 和邮箱插入到日志表，就该写成：
INSERT INTO user_log (user_id, email, created_at) SELECT id, email, NOW() FROM users WHERE status = 'active';
这种写法天然支持多行插入、字段映射和条件过滤，也避免了手动拼接值的风险。
VALUES 中不能直接嵌套 SELECT，但 PostgreSQL 支持 VALUES + 子查询组合
标准 SQL 的 VALUES 只接受字面量或参数占位符，不能放 SELECT。不过 PostgreSQL 是个例外：它允许在 VALUES 列表中用 (SELECT ...) 作为单个标量表达式，前提是子查询必须返回**恰好一行一列**。例如：
INSERT INTO config (key, value) VALUES
('max_retries', (SELECT COALESCE(MAX(retry_count), 3) FROM tasks)),
('timeout_sec', 30);
注意：(SELECT ...) 必须用括号包住，且不能返回多行（否则报错 more than one row returned by a subquery）；MySQL 和 SQL Server 不支持这种写法，会直接报语法错误。
INSERT ... SELECT 需要严格匹配列数和数据类型
目标表的字段数、顺序、类型必须和 SELECT 结果集对齐，否则会失败。常见翻车点包括：
-
SELECT返回 3 列，但INSERT INTO t(a,b)只写了 2 个目标字段 → 报错Column count doesn't match value count -
SELECT CAST('2024' AS CHAR)插入到DATE类型字段 → 类型隐式转换失败（尤其在严格模式下） - MySQL 中
SELECT NOW()插入TIMESTAMP字段没问题，但插入DATETIME时若时区配置不一致，可能存入意外时间
子查询里带 LIMIT 或 ORDER BY 容易被忽略执行顺序
INSERT INTO ... SELECT 中的 ORDER BY 和 LIMIT 不是可选装饰，而是实际影响结果集——尤其当你依赖顺序生成序号或取最新一条记录时。例如：
INSERT INTO top_users (user_id, score) SELECT user_id, score FROM user_scores ORDER BY score DESC LIMIT 10;
这里 ORDER BY ... LIMIT 是在子查询内部执行的，不是插入后再排序。但要注意：ORDER BY 在无索引字段上可能拖慢性能；SQLite 不支持 INSERT ... SELECT 带 LIMIT（需用 CTE 包一层）；而 SQL Server 要求带 TOP 而非 LIMIT。
真正容易被绕进去的是：你以为子查询“先算完再插”，其实优化器可能把外层条件下推，导致结果和单独执行 SELECT 不一致——调试时务必把子查询单独跑一遍对比输出。
