INSERT INTO ... SELECT 比逐条 INSERT 快，因单次完成全量搬运，避免多次网络往返和事务开销；常用临时表作数据源，需注意字段匹配、主键冲突、索引优化及分批提交等关键点。
INSERT INTO ... SELECT 为什么比逐条 INSERT 快？
因为单次语句完成全量数据搬运，避免了多次网络往返和事务开销。临时表 #temp 或 ##global_temp 中的数据在会话或作用域内可直接被 SELECT 访问，INSERT INTO target_table SELECT ... FROM #temp 是最常用路径。
常见错误是漏写 WHERE 条件导致重复插入，或没处理目标表主键/唯一约束冲突。SQL Server 默认不自动跳过冲突行，会直接报错 Violation of PRIMARY KEY constraint。
- 确保目标表字段顺序、类型与
SELECT列严格匹配（尤其datetime和datetime2不兼容） - 若目标表有自增列，且不想用源数据值，需显式列出目标字段名，避开该列；否则加
SET IDENTITY_INSERT target_table ON - 大体积插入前建议关闭索引（
DISABLE INDEX），完事后重建，否则性能可能下降 5–10 倍
如何安全跳过重复数据（ON DUPLICATE KEY 替代方案）？
SQL Server 没有 MySQL 的 ON DUPLICATE KEY UPDATE，但可用 MERGE 实现类似效果。它本质是“查+判+插/更”原子操作，适合带唯一键的去重场景。
典型误用是把 MERGE 当成简单插入——没写 WHEN NOT MATCHED THEN INSERT 就只做更新，或者漏掉 OUTPUT 导致无法确认实际影响行数。
-
MERGE必须搭配USING和ON，且ON条件字段需有索引，否则性能极差 - 目标表别名（如
AS T）不能省略，否则语法报错The MERGE statement attempted to UPDATE or DELETE the same row more than once - 若只需插入不重复行，用
NOT EXISTS更轻量：INSERT INTO t SELECT * FROM #temp WHERE NOT EXISTS (SELECT 1 FROM t WHERE t.id = #temp.id)
批量插入时怎么控制内存和日志增长？
默认完整日志模式下，百万级插入会撑爆 tempdb 和事务日志。关键不是“能不能快”，而是“会不会卡死或填满磁盘”。
常见做法是分批提交，但切忌用 TOP 1000 配合 OFFSET/FETCH——无索引排序时性能随偏移量线性恶化。
- 按主键/有序字段分段，例如
WHERE id BETWEEN @start AND @end，配合WHILE循环 - 每批设
COMMIT，并调大@@ROWCOUNT判断是否继续，避免空跑 - 临时切换数据库恢复模式为
BULK_LOGGED（仅限非生产环境测试验证后使用），能大幅减少日志量
临时表跨会话不可见，那正式表插入失败后怎么查原始数据？
#temp 表生命周期绑定会话，一旦连接断开或脚本执行结束就自动销毁。这意味着插入中途出错，你没法再 SELECT * FROM #temp 查原因。
真正可靠的做法不是依赖临时表存活，而是提前把数据固化到持久对象中——哪怕只是个带 ON COMMIT PRESERVE ROWS 的全局临时表（SQL Server 不支持），所以得换思路。
- 开发阶段优先用物理表（如
staging_orders）替代#temp，加create_date DATETIME2 DEFAULT GETDATE()方便追溯 - 如果必须用临时表，插入前先
SELECT COUNT(*) INTO #temp_count FROM #temp，出错时至少知道源数据量 - 错误捕获别只靠
@@ERROR，要用TRY...CATCH+ERROR_MESSAGE()记录具体哪一行、哪个字段触发了约束失败
临时表本身不保存状态，它的价值在于中间计算，而不是数据保险柜。真要保底，就得把“临时”这层去掉。
