SQL Server 百万级数据SELECT INTO批量加载方法

SELECT ... INTO本身的语法设计不支持配合FETCH/LIMIT实现分批加载。
这个语句的执行逻辑是“单次解析全量结果集、一次性创建目标表结构、一次性写入所有结果”，哪怕你在SELECT子句里加TOP/OFFSET FETCH限制返回行数，也只会在第一次执行时生成表并写入第一批数据；后续重复执行同一条带INTO的语句，会直接抛出“数据库中已存在目标表”的错误，根本没法靠INTO本身完成多批数据的累计写入。
你测100条数据只要2ms、但全量1500万条要跑2小时，问题根本不是查询本身的扫描成本（你算下总逻辑读也就4亿左右，正常存储几秒就能扫完），而是单个超长大事务带来的连锁问题：日志暴涨、锁升级阻塞业务、执行计划选了全表扫的低效路径、长事务阻塞日志截断导致磁盘空间占满。

完全可以在你原有SELECT INTO逻辑的基础上，把大操作拆成小批量写入，同时保持和原生SELECT INTO一致的最小日志写入效率，不会额外增加IO开销：

• 第一步：先单独创建空的目标表结构
  跑一次带TOP 0的原查询，仅生成和你预期字段、类型完全一致的空表，不写入任何数据，这一步是毫秒级完成的，相当于把原来全量SELECT INTO里的“自动建表”动作提前拆出来：

  -- 仅生成表结构，无数据写入
  SELECT TOP 0
    col, col, col, col_n
  INTO dbo.new_table
  FROM tbl 
  LEFT JOIN tbl_a ON /* 填写你的原JOIN关联条件 */
  LEFT JOIN tbl_b ON /* 填写你的原JOIN关联条件 */
  LEFT JOIN tbl_n ON /* 填写你的原JOIN关联条件 */
  

• 第二步：循环批量插入数据，保持原有的写入性能
  往已经建好的空表插数据时，只要加WITH (TABLOCK)表提示，就会触发和原生SELECT INTO完全相同的最小日志批量写入路径，不会因为拆批多写日志。
  分片的时候绝对不要用OFFSET/FETCH跳行分批，这种方式越往后扫描成本越高——比如你要取第100万到110万条数据，SQL Server要先把前面100万条全部扫一遍才能跳过，到最后几批的扫描成本会比全量扫还高。正确的分片方式是拿主表上的单调唯一键（比如主键ID）作为切片边界，每批按ID范围过滤：

  DECLARE
    @BatchSize INT = 100000, -- 每批10万行，可根据服务器内存调整到50-200万行
    @MaxProcessedId BIGINT = 0,
    @CurrentMaxId BIGINT;
  
  WHILE 1 = 1
  BEGIN
    -- TABLOCK提示触发最小日志写入，和原SELECT INTO写入效率一致
    INSERT INTO dbo.new_table WITH (TABLOCK)
    (col, col, col, col_n)
    SELECT
      col, col, col, col_n
    FROM tbl
    LEFT JOIN tbl_a ON /* 填写你的原JOIN关联条件 */
    LEFT JOIN tbl_b ON /* 填写你的原JOIN关联条件 */
    LEFT JOIN tbl_n ON /* 填写你的原JOIN关联条件 */
    -- 按主键ID范围过滤，走索引Seek，避免全表扫描
    WHERE tbl.primary_id > @MaxProcessedId
      AND tbl.primary_id <= @MaxProcessedId + @BatchSize;
  
    -- 更新分片边界，推进循环
    SELECT @CurrentMaxId = MAX(primary_id) FROM dbo.new_table;
  
    -- 没有新数据则退出循环
    IF @CurrentMaxId = @MaxProcessedId BREAK;
    SET @MaxProcessedId = @CurrentMaxId;
  END
  

• 拆批之后，原来2小时的单个大事务会被拆成十几个小事务，每批的事务持有时间只有几秒，不会出现长事务导致的日志文件暴涨、锁升级阻塞业务、中途失败要回滚几小时的问题。
• 如果你的数据库是完整恢复模式，不管是SELECT INTO还是批量插入，日志量都会比简单/大容量日志模式高很多；临时把目标库切到大容量日志模式跑批量操作，速度会有明显提升，跑完再切回完整模式即可。
• 你之前测100条样本的逻辑读是2641，是因为小样本下优化器会选低成本的嵌套循环执行计划；但全量跑的时候，优化器会因为要一次性处理1500万行，自动切换成全表扫+Hash Join的方案，实际IO会高很多。拆批之后因为每批有ID范围过滤，优化器会自动走索引Seek的执行路径，实际每批的逻辑读会比全量扫低30%-50%。

补充：如果你确实需要限制单批返回的数据量，完全可以在上面的插入语句里加FETCH，但没必要——你已经用主键范围做了精准分片，额外加FETCH反而可能误导优化器选择低效的执行计划。

内容的提问来源于stack exchange，提问作者marcin2x4