我有一个每月的 ETL 过程，这里太复杂了，无法解释，但基本上我们会获得大量客户数据，将其批量加载到各种表中，然后运行一系列构建过程。
总数据量很大，我们每月添加25-30m条记录到最大的表中，总共有大约700m条记录。每个也有 2m-300m 记录的支持表。该集合的总数据约为 3.5TB。
本月，某些流程所花的时间比平时长得多。一个例子是一个通常在 30 分钟内完成的过程在我杀死它之前花了大约 40 个小时（它仍然没有完成）。
并非所有流程都受到影响，有些流程甚至比平时运行得更快。
显然，根本原因超出了我在这里可以问的范围，但有些事情困扰着我：
我们有以数百万百分比显示的各个运营商的实际查询计划。
就像针对 的聚集索引扫描、针对791,358,704%的合并连接75,566,494%等。这发生在多个查询计划中，这些计划取自sys.dm_exec_query_plan。
这些查询计划是否指示其他一些更大的问题？
我可以肯定地知道问题不是过时的统计数据——我们对所有主要表运行了全扫描，并且我手动重建了最大的表和数据库，并预先调整大小以消除碎片。
JNK,
你的意思是这样的？
http://sankarreddy.com/wp-content/uploads/2011/03/CropperCapture2.jpg
这是根据客户端工具的统计数据生成的估计执行计划，请注意这不是引擎问题。如果您希望 MSFT 解决此问题，请为该连接项目投票。
https://connect.microsoft.com/SQLServer/feedback/details/436184/huge-operator-cost-in-estimated-execution-plan
由于您提到了 SQL Server 2008，我建议您在作业运行时查看 WAIT STATS 信息。查看为什么执行没有进展并找出瓶颈。
http://blogs.technet.com/b/sqlos/archive/2008/07/18/debugging-slow-response-times-in-sql-server-2008.aspx
此外，查看 sys.virtualfilestats 信息，看看是否存在明显的 IO 滞后以及内存使用情况。
HTH