SQL Server,TOP与ROW_NUMBER


8

我正在学习执行计划,并尝试不同的查询并比较它们的性能,结果发现:

SELECT StatisticID
FROM (
    SELECT StatisticID, ROW_NUMBER() OVER (ORDER BY StatisticID) AS rn
    FROM FTCatalog.Statistic
    ) AS T
WHERE T.rn <= 1000
ORDER BY rn

SELECT TOP 1000 StatisticID
FROM FTCatalog.Statistic
ORDER BY StatisticID

它们都返回相同的结果集-但是第一个执行速度更快,资源占用更少(至少SSMS告诉我),以下是执行计划: 执行计划

与SQL Query Plan Explorer的比较: 在此处输入图片说明 谁能给我一些有关幕后实际发生情况的信息,以及为什么结果有所不同?如果您还有其他需要,请告诉我。

谢谢,伊瓦达斯。


由于某种原因,SQL Server对于分页查询没有很好的查询重写。在这种常见情况下,计划和估计上的这些差异不应该存在。
usr

Answers:


11

我想您正在比较查询的估计费用。这些只是基于(除其他事项外)查询返回的估计行数的估计。不是实际的行数。

您的第一个查询估计它将返回30行,而第二个查询估计将返回1000行。那就是您查询成本差异的来源。

如果将查询更改为仅获取30行,您将看到查询的估计行是相同的,并且第一个查询的开销实际上要高一些,至少对于我来说是SQL Server 2014。

比较查询性能时,请勿使用估算值。使用诸如持续时间,读取次数和内存授予大小之类的东西。


1
为了确定实际性能,请使用“包括客户端统计信息”选项多次运行每个查询(GO 10)。我怀疑您会发现实际执行时间比相对成本估算要短。幕后没有魔法。查询计划运算符讲述了真实的故事。
丹·古兹曼

相对成本(百分比表示)在SSMS中实际上意味着什么吗?那让我最烦。
Evaldas Buinauskas

@EvaldasBuinauskas不确定相对成本是否对任何事情都有用。也许有时候,但我认为,当人们开始使用估计的百分比来比较不同查询的性能时,它所造成的所有混乱是不值得的。这将永远是一个估计,而估计总是(几乎)是错误的。
Mikael Eriksson

@EvaldasBuinauskas,这些费用是在优化过程中收集并公开的,但并不是要作为指标或实际运行时间。费用只是最好的猜测。参见blogs.msdn.com/b/sqlqueryprocessing/archive/2006/10/11/…–
Dan Guzman
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.