Sql server 2012 通过SSIS包将大型扁平文件加载到SQL表的速度太慢

我每周都会收到大约8个巨大的带分隔符的扁平文件，这些文件将加载到SQL server（2012）表中。所有文件中的总行数大约为1.5亿行，每个文件具有不同的行数。我有一个简单的SSIS包，它将数据从flatfiles（使用foreach容器）加载到历史表中。然后在此历史记录表上运行select查询，以选择当前周数据并加载到临时表中

当历史记录表变得非常大（80亿行）时，我们遇到了问题。所以我决定备份历史表中的数据并截断。在截短之前，包的执行时间从15小时到63小时不等。我们希望截短之后应该回到15小时或更少。但令我惊讶的是，即使在20多小时之后，包仍然在运行。最糟糕的是，它仍在加载历史记录表。最新统计数字约为1.2亿。它仍然需要加载暂存数据，并且可能需要同样长的时间

历史记录表和临时表都没有任何索引，这就是为什么对历史记录表执行select查询占用了大部分执行时间的原因。但从所有平面文件加载到历史记录表的时间总是少于3小时。 我希望我说的有道理。有人能帮我理解这周不寻常的执行时间背后的原因吗？谢谢

注意：在3分钟内从平面文件源读取了最大的文件（8GB）。所以我认为源代码并不是这里的瓶颈。

没有充分的理由，IMHO，为什么服务器需要那么长时间才能加载这么多数据。你是说这个过程过去需要3个小时，现在需要60多个小时？是第一部分（数据加载）还是第二部分（历史表）突然变慢？或者，两者同时出现

我想我要做的第一件事是“信任，但要验证”这里没有索引。我要看的第二件事是这个表空间的存储分配。。。它是否已经没有空间了，以至于SQL server必须做大量额外的工作来获取和维护存储？这个过程是如何提交的？每排之后？你能证明最近包的定义没有丝毫改变吗

显然，“1.5亿行”并不是很多数据，这些天；8GB也是如此。如果您只是“简单地”将这些行移动到一个未编制索引的表中，那么“3小时”将是一个慷慨的期望。显然，这种行为唯一可靠的根本原因是磁盘I/O负载急剧增加，我健康地怀疑“过度提交”可能是原因的一部分：重新写入而不是“延迟写入”，重新读取而不是缓存