INSERT INTO ... SELECT 必须为单条语句，不可分步执行；目标表存在时需列数、顺序、类型兼容，不存在时可用 CREATE TABLE AS SELECT（各数据库行为不同），冲突处理需依赖唯一约束及对应语法（如 ON DUPLICATE KEY、ON CONFLICT、MERGE）。
INSERT INTO ... SELECT 语法必须写成单条语句
不能先写 SELECT 再手动复制结果去 INSERT，SQL 不支持这种“分步粘贴”操作。正确做法是把查询逻辑直接嵌进 INSERT 语句里，由数据库一次性执行。
常见错误是漏掉目标表字段列表或类型不匹配：
- 如果目标表已存在，
INSERT INTO new_table SELECT ...要求SELECT返回的列数、顺序、类型能隐式兼容目标表结构 - 如果目标表不存在，得用
CREATE TABLE new_table AS SELECT ...（注意：不同数据库对AS SELECT的支持有差异） - MySQL 支持
CREATE TABLE ... SELECT，但不会继承原表的索引、主键、默认值；PostgreSQL 需用CREATE TABLE ... AS SELECT+ 后续ALTER补约束
CREATE TABLE AS SELECT 在 PostgreSQL 和 MySQL 中行为不同
CREATE TABLE new_tab AS SELECT * FROM old_tab; 看似简单，但实际效果取决于数据库：
- PostgreSQL：新表只有数据和列定义，无主键、无索引、无约束、无默认值，且
oid不复制 - MySQL（5.7+）：同样不复制 KEY/CONSTRAINT，但会保留
NOT NULL属性（若源列定义了）；8.0 开始支持WITH NO DATA控制是否带数据 - SQL Server 不支持
CREATE TABLE AS SELECT，只能用SELECT ... INTO new_table（该语句会自动建表，但仅限当前会话可用，且不能在已有表上运行）
INSERT INTO ... SELECT 遇到主键/唯一冲突怎么办
目标表已有数据，又想插入新记录，直接执行 INSERT INTO t2 SELECT * FROM t1 很可能报 duplicate key 错误。这时不能靠“忽略”糊弄过去，得明确策略：
- MySQL 可用
INSERT IGNORE INTO（跳过冲突行）或ON DUPLICATE KEY UPDATE（冲突时更新） - PostgreSQL 用
INSERT ... ON CONFLICT DO NOTHING或DO UPDATE（需指定冲突目标，如ON CONFLICT (id)） - SQL Server 用
MERGE语句，逻辑更显式但语法冗长；避免用NOT EXISTS子查询套INSERT，性能差且易漏锁 - 所有方案都要求目标表有明确定义的唯一约束（PRIMARY KEY 或 UNIQUE），否则
ON CONFLICT/ON DUPLICATE KEY无法触发
大数据量 INSERT INTO ... SELECT 的性能陷阱
从千万级表导出数据时，看似一条语句很轻量，实则容易卡住或爆日志：
- 事务日志暴涨：MySQL 的
innodb_log_file_size、PostgreSQL 的wal_level和检查点间隔都会影响；建议分批加LIMIT+OFFSET（但注意OFFSET大时效率也低） - 锁表现不一：MySQL 默认语句级锁，PostgreSQL 是行级，但全表
SELECT仍可能触发AccessShareLock，阻塞其他 DML - 临时空间吃紧：某些数据库会在
SELECT阶段缓存中间结果，ORDER BY或GROUP BY更甚；能去掉就去掉 - 别在生产高峰期跑全表
INSERT ... SELECT，尤其跨库或跨实例时——网络延迟 + 序列化开销可能远超预期
真正快的不是语法多短，而是清楚每一步数据库在做什么、锁什么、写什么日志。
