的SQL Server ORDER BY性能像差

SQL Server 2008上的Windows服务器企业（？）上运行的2008年版的SQL Server ORDER BY性能像差

我有一个查询加入对20的一些奇表（主要是左外连接）。未筛选查询返回的完整数据集在少于1秒的时间内返回少于1,000行。当我应用WHERE子句来过滤查询时，它会在少于1秒的时间内返回少于300行。

当我将ORDER BY子句应用于查询时，它在90年代返回。

我检查了查询的结果，并注意到正在用于排序的列中返回的一些NULL结果。我将查询修改为COALESCE将NULL值更改为有效的搜索值，而不会改变查询的性能。

然后我做了一个

SELECT * FROM 
(
my query goes here 
) qry 
ORDER BY myOrderByHere

和产生相同的结果。

当我SELECT ... INTO #tempTable（没有ORDER BY），然后从查询返回的顺序通过#tempTable从小于1秒返回。

现在真正奇怪的是，即使没有ORDER BY，SELECT ... INTO也将花费90秒。

执行计划表示，当SORT包含在主查询中时，执行时间占98％。如果我正在执行INSERT INTO，解释计划说实际插入临时表需要99％的执行时间。

为了解决服务器问题，我对SQL Server 2008的两个不同实例运行了相同的测试，结果几乎相同。

非常感谢！

rjsjr

来源

2010-10-04 Mr. Wobbet

排序操作通常是查询中昂贵的步骤。所以，排序的添加增加了时间并不奇怪。当您在步骤中加入临时表时，您可能会看到类似的结果。原始查询中的排序操作可能使用tempdb来帮助完成排序，并且这可能是您比较的每个查询中耗时的步骤。

如果您想了解有关您运行的每个查询的更多信息，可以查看查询计划输出。

来源

2010-10-04 21:49:48 bobs

听起来像一些奇怪的事情正在与你的tempdb进行。在临时表中插入1000行应该很快，无论是用于排序的隐式假脱机还是明确的select into。

检查你的tempdb的大小，硬盘这是对健康，它的恢复模式（应该是simple，不full或bulk logged。）

来源

2010-10-04 22:16:07 Andomar

在我的开发/测试服务器tempdb数据库400MB大，有400MB的空间可用。在恢复下我看到页面验证选项设置为CHECKSUM。我确保日志文件被截断并重新运行测试，结果没有任何变化。我也尝试将查询的主体移到VIEW中，并在该视图上执行SELECT和ORDER。这产生了相同的结果。 – 2010-10-05 14:15:03

的SQL Server ORDER BY性能像差

回答

相关问题