Sql server 2008 查询性能比较

我完全混淆了一些“类似”语句的运行时性能

select * from  DLIFE.IS_TABLE_REPORT where [project_name] = 'myProject'
-- (82 row(s) affected) in 02:10

现在，如果我尝试在另一个查询中使用此查询返回的记录，则执行所需的时间将延长4倍或更多。 我能想到的证明这一点的最简单例子如下：

select * into #temp
from  DLIFE.IS_TABLE_REPORT where [project_name] = 'myProject'
-- (82 row(s) affected) in 08:10

因此，出于某种原因，将82行写入临时表“似乎”需要6分钟！？ 这里发生的事情比我想象的还要多

从执行计划和统计数据来看，两者之间存在很大差异。 我原以为他们几乎是一样的

突然间我意识到我知道的太少了

统计数字：

挑选

Table 'Key_Column_Definitions_Header'.  Scan count 0, logical reads 202
Table 'Worktable'.                      Scan count 2,952,361, logical reads 24,753,476;
Table 'DLIFE_Med_Short'.                Scan count 101, logical reads 41,496, read-ahead reads 1, 
Table 'DLIFE_IS_FD_RUN_HISTORY'.        Scan count 1, logical reads 88, 

选择进入

Table 'Worktable'. Scan count 3825785, logical reads 29,257,307, physical reads 6,513; 
Table 'DLIFE_Med_Short'. Scan count 82, logical reads 40660, 
Table 'DLIFE_IS_FD_RUN_HISTORY'. Scan count 9, logical reads 182, 
Table 'Key_Column_Definitions_Header'. Scan count 1, logical reads 4, read-ahead reads 3,

执行计划

---

使用

选择时会发生什么情况。。。进入选择。。。选项（合并加入）

？不确定您的建议中的第二个选择，但以下内容似乎对事情进行了排序：select*into。。来自DLIFE.IS_表_报告，其中。。选项（合并联接）。所以非常感谢：）但是，现在我有一个问题，您不能在视图定义中包含选项。我的视图将由第三方应用程序调用，该应用程序只能按名称访问表/视图。如此接近。！有什么想法吗？更新：所以使用选项（合并连接）解决了我的问题的上述具体实例。然而，我现在看到的是另一个类似的例子，O（MJ）并没有解决这个问题。我想这件事的根源在于理解为什么会出现这种情况。我的新情况与上面的情况非常相似，一个查询本身只需13秒就可以运行。然而，若我试图对结果做任何事情（例如：进一步的计算，插入到表中），那个么QPlan会发生变化，性能会下降3到4倍。有谁能帮助我们进一步了解引擎盖下正在发生的事情吗？O（MJ）并不是所有性能问题的解决方案。如果有另一个“类似”的查询存在性能问题，请执行相同的步骤：发布另一个问题，包括执行计划。好的，可以-谢谢：）