INSERT INTO ... SELECT 是批量导入的正解，它天然适配多行结果集，兼容主流数据库；而 INSERT INTO ... VALUES 嵌套子查询仅支持单值单行，易因多行返回报错。
INSERT INTO ... SELECT 是批量导入的正解，不是 INSERT INTO ... VALUES 嵌套子查询
直接在 VALUES 后面写子查询（比如 INSERT INTO t VALUES ((SELECT id FROM s WHERE ...))）只能插入单值、单行，且极易因子查询返回多行报错 Subquery returns more than 1 row。真正支持批量导入的语法是 INSERT INTO ... SELECT —— 它天然适配多行结果集，也是 MySQL/PostgreSQL/SQL Server 都兼容的标准写法。
常见错误现象：用 VALUES 强塞子查询，一跑就崩；或误以为加个 IN 就能批量，结果只插了第一行。
-
INSERT INTO target (a, b) SELECT x, y FROM source WHERE ...是唯一可靠方式 - 子查询可带
JOIN、WHERE、GROUP BY，甚至嵌套另一层SELECT - 目标表字段数量、类型必须与
SELECT列严格匹配（顺序也要一致） - PostgreSQL 中若目标列有默认值且未在
SELECT中提供，需显式写DEFAULT占位（MySQL 允许省略）
避免 NULL 插入失败：显式处理缺失值和类型转换
子查询结果里常含 NULL，而目标字段若定义为 NOT NULL 且无默认值，整条 INSERT 就会中止。别指望数据库自动跳过——它会直接报错 Column 'xxx' cannot be null。
使用场景：从日志表提取用户行为，但某些字段在原始数据中为空；或跨库同步时字段精度不一致（如源是 DECIMAL(10,2)，目标是 INT）。
- 用
COALESCE(col, 0)或COALESCE(col, 'N/A')替换NULL - 数值类强制转换：MySQL 用
CAST(col AS SIGNED)，PostgreSQL 用col::INTEGER - 字符串截断防超长：
LEFT(col, 255)（MySQL）或SUBSTR(col, 1, 255)（PG） - 日期格式不一致时，先用
STR_TO_DATE()（MySQL）或TO_DATE()（PG）转标准DATE
性能卡在全表扫描？给子查询加索引和限制条件
如果子查询没走索引，比如 SELECT u.id, u.name FROM users u WHERE u.status = 'active'，但 status 字段没索引，那每次 INSERT 都会触发全表扫描，几万行就明显变慢。
更隐蔽的问题：子查询里用了函数（如 UPPER(email)），导致索引失效；或者 JOIN 条件字段类型不一致（VARCHAR 对 CHAR），隐式转换拖垮性能。
- 检查执行计划：
EXPLAIN INSERT INTO ... SELECT ...（MySQL）或EXPLAIN ANALYZE（PostgreSQL） - 确保 WHERE、JOIN、ORDER BY 涉及的字段都有索引，尤其是高基数字段（如
user_id） - 避免在 WHERE 中对字段做函数操作；改用
email LIKE 'a%'代替UPPER(email) = 'A@B.COM' - 大批量导入时，先
CREATE TEMP TABLE存中间结果，再从临时表INSERT，比反复查原表快得多
事务和重复键冲突：ON DUPLICATE KEY UPDATE 和 INSERT ... ON CONFLICT
批量导入最常踩的坑不是语法，而是主键/唯一键冲突。MySQL 报 Duplicate entry 'xxx' for key 'PRIMARY'，PostgreSQL 报 duplicate key value violates unique constraint，然后整个语句回滚——哪怕只有一行冲突。
解决思路不是删重再插，而是让 SQL 自己处理冲突：
- MySQL：用
INSERT INTO t (...) SELECT ... ON DUPLICATE KEY UPDATE col = VALUES(col) - PostgreSQL：用
INSERT INTO t (...) SELECT ... ON CONFLICT (id) DO UPDATE SET col = EXCLUDED.col - 注意
ON CONFLICT必须指定冲突列（通常是PRIMARY KEY或UNIQUE约束名），不能只写ON CONFLICT DO NOTHING（除非真想丢弃冲突行） - 如果目标表有自增主键，且子查询没提供该列，MySQL 允许忽略；但 PostgreSQL 要么设
GENERATED ALWAYS，要么显式写DEFAULT
真正复杂的是业务逻辑冲突：比如“存在则更新金额，但不覆盖创建时间”。这时候不能只靠 ON DUPLICATE KEY，得在子查询里提前用 ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC) 去重，再拼进主 INSERT —— 否则数据库层面没法判断哪条记录“更新优先级更高”。
