对于我尝试优化的中等复杂查询,我注意到删除TOP n
子句会更改执行计划。我猜想,当查询包含TOP n
数据库引擎时,会运行查询而忽略该TOP
子句,然后最后将结果集缩小到请求的n行数。图形执行计划似乎表明情况确实如此——TOP
是“最后”一步。但似乎还有更多事情发生。
我的问题是,TOP n 子句如何(以及为什么)影响查询的执行计划?
这是我的情况的简化版本:
查询匹配来自两个表 A 和 B 的行。
如果没有该TOP
子句,优化器估计将有来自表 A 的 19k 行和来自表 B 的 46k 行。返回的实际行数是 A 的 16k 和 B 的 13k。哈希匹配用于连接这两个结果集总共 69 行(然后应用排序)。此查询发生得非常快。
当我添加TOP 1001
优化器时不使用哈希匹配;相反,它首先对表 A 的结果进行排序(与 19k/16k 相同的估计值/实际值)并对表 B 执行嵌套循环。表 B 的估计行数现在为 1,奇怪的是TOP n
直接影响对 B 的估计执行次数(索引搜索) - 它似乎总是2n+1,或者在我的情况下是 2003 年。如果我改变,这个估计会相应地改变TOP n
。当然,由于这是嵌套连接,因此实际执行次数为 16k(表 A 中的行数),这会减慢查询速度。
实际场景有点复杂,但这捕获了基本思想/行为。两个表都使用索引查找进行搜索。这是 SQL Server 2008 R2 企业版。
performance sql-server optimization execution-plan query-performance
我有一个查询,它使用 select 运行得更快,top 100
而不使用top 100
. 返回的记录数为 0。你能解释一下查询计划的差异或分享解释这种差异的链接吗?
top
文本的查询:SELECT --TOP 100
*
FROM InventTrans
JOIN
InventDim
ON InventDim.DATAAREAID = 'dat' AND
InventDim.INVENTDIMID = InventTrans.INVENTDIMID
WHERE InventTrans.DATAAREAID = 'dat' AND
InventTrans.ITEMID = '027743' AND
InventDim.INVENTLOCATIONID = '???? ?????' AND
InventDim.ECC_BUSINESSUNITID = '?????????';
Run Code Online (Sandbox Code Playgroud)
top
):top
):SQL Server parse and compile time:
CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times:
CPU time = …
Run Code Online (Sandbox Code Playgroud) performance sql-server t-sql query-performance performance-tuning