直接INSERT INTO...SELECT大批量插入易卡顿超时，因SQL Server将其视为单事务致日志暴涨、锁表过长；应先载入临时表再分批提交，用WHILE+TOP N按ID游标安全批量插入。
为什么直接 INSERT INTO ... SELECT 会卡住或超时
大批量插入时，如果用单条 INSERT INTO target SELECT * FROM source 拉取几十万行，容易触发事务日志暴涨、锁表时间过长、内存溢出等问题。SQL Server 默认把整条语句当一个隐式事务处理，没提交前所有数据都压在日志里，同时阻塞其他读写操作。
临时表本身不解决性能问题，但它是可控分批的起点——先把数据“卸”到 #staging 里，再按需切片插入目标表。
- 避免跨库/跨服务器直连查询带来的网络抖动和超时（尤其链接服务器场景）
- 可在临时表上加索引或统计信息，加速后续 JOIN 或 WHERE 过滤
- 失败后可重试某一批，而不是整批回滚重跑
如何用 WHILE 循环 + TOP N 实现安全批量提交
不用游标，也不依赖 OFFSET/FETCH（低版本不支持），最稳的方式是用自增 ID 或时间戳做游标位移。前提是源数据有唯一递增列（如 id 或 created_at）。
DECLARE @BatchSize INT = 5000; DECLARE @MinID BIGINT = 0, @MaxID BIGINT; <p>SELECT @MaxID = MAX(id) FROM #staging;</p><p>WHILE @MinID < @MaxID BEGIN INSERT INTO dbo.target_table (col1, col2, col3) SELECT col1, col2, col3 FROM #staging WHERE id > @MinID AND id <= @MinID + @BatchSize;</p><pre class='brush:php;toolbar:false;'>SET @MinID = @MinID + @BatchSize; CHECKPOINT; -- 强制写入日志缓冲区（仅适用于简单恢复模式） WAITFOR DELAY '00:00:00.01'; -- 防止 CPU 空转（可选）
END
-
CHECKPOINT在简单恢复模式下能及时截断日志，避免log_full错误；完整模式下无效，得靠日志备份释放空间 - 别用
@@ROWCOUNT判断是否还有数据——最后一批可能不足@BatchSize，但循环仍需继续 - 如果没合适排序列，可用
SELECT TOP (@BatchSize) ... ORDER BY (SELECT NULL)配合OUTPUT INTO #batch做无序分片，但无法保证不重复
临时表命名与作用域陷阱
本地临时表（#name）只在当前会话可见，存储过程结束自动销毁，这点很安全。但要注意：动态 SQL 中创建的 #temp 表，在外部无法引用——因为作用域隔离。
- 在存储过程开头就建好
#staging，别在EXEC()里建，否则后续INSERT会报Invalid object name '#staging' - 如果要复用已有结构，用
SELECT TOP 0 * INTO #staging FROM source快速建表，比手写CREATE TABLE少出错 - 不要对
#staging建聚集索引（除非后续频繁按某列查），非聚集索引也只加真正用到的字段，索引越多，INSERT越慢
SET NOCOUNT ON 和 XACT_ABORT 的实际影响
默认每执行一条语句，SQL Server 都返回 “(X rows affected)” 消息。大批量插入时，这些消息堆积会拖慢客户端接收速度，甚至让 SSMS 卡死。
- 必须开头加
SET NOCOUNT ON，否则 .NET 的SqlCommand.ExecuteNonQuery()可能抛出超时异常 -
SET XACT_ABORT ON是关键：遇到运行时错误（如主键冲突、类型转换失败）时，整个事务立刻终止并回滚，避免部分提交导致数据不一致 - 别依赖
TRY...CATCH捕获每批错误——它不能回滚已提交的批次；真要细粒度控制，得把每批包进独立事务里（但会增加日志开销）
批量大小不是越大越好，5000 是多数 OLTP 场景的甜点值；超过 10000 容易触发锁升级（page lock → table lock），反而降低并发。实测前务必在测试库用 SET STATISTICS IO, TIME ON 观察逻辑读和执行时间。
