我在查询中使用了不同的临时表。当我执行下面的查询时
select * from myView
执行只需 5 秒。
但是当我执行
select * into #temp from myView
它需要 50 秒(比上述查询多 10 倍)。
我们从 SQL Server 2000 迁移到 SQL Server 2008 R2。在 SQL 2000 之前,这两个查询都需要相同的时间,但在 SQL Server 2008 中,执行时间要多 10 倍。
我在查询中使用了不同的临时表。当我执行下面的查询时
select * from myView
执行只需 5 秒。
但是当我执行
select * into #temp from myView
它需要 50 秒(比上述查询多 10 倍)。
我们从 SQL Server 2000 迁移到 SQL Server 2008 R2。在 SQL 2000 之前,这两个查询都需要相同的时间,但在 SQL Server 2008 中,执行时间要多 10 倍。
老问题,但是由于我遇到了类似的问题(尽管在 SQL Server 2014 上)并以我在任何现成资源上都没有看到的方式解决了它,我想我会分享它以希望它对其他人有所帮助。
我遇到了类似的情况:我创建的视图需要 21 秒才能返回其完整的结果集,但是当我将其转换为一个简单SELECT..INTO
的视图时需要 10 多分钟(此时我停止了查询)SELECT
没有连接也没有谓词。我的预感是优化器正在根据附加INTO
语句更改原始计划,该语句并没有像第一个实例那样简单地提取数据集,然后执行INSERT
,而是以一种非常次优的方式对其进行更改。
我首先尝试了一个OPENQUERY
,试图强制先生成结果集,然后插入到临时表中。该方法的总运行时间为 23 秒,显然与原来的SELECT
时间更接近。在此之后,我返回到我的原始SELECT..INTO
查询并添加了一个OPTION (FORCE ORDER)
提示以尝试复制该OPENQUERY
行为。这似乎成功了,时间与OPENQUERY
方法相当,23秒。
我目前没有足够的时间来比较查询计划,但是如果您遇到此问题,作为一个快速而肮脏的选择,您可以尝试:
select * into #temp from myView option (force order);
是的,我会检查你的命令的执行计划。排序或其他东西可能会有开销。
我认为,您的 tempdb 数据库有问题。可能是缓慢的 I/O、碎片、损坏的 RAID 等。
您的 select 语句中是否有 order by 子句,例如select * from myView order by col1
在插入临时表之前?如果有订单,则会大大减慢插入临时表的速度。如果是这种情况,请在插入发生时删除 order by 并在插入发生后 order by
select *
into #temp
from myView
然后申请订单
select * from #temp order by col1