相关疑难解决方法(0)

对于我尝试优化的中等复杂查询，我注意到删除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 企业版。

我有以下查询：

select databasename 
from somedb.dbo.bigtable l where databasename ='someval' and source  <>'kt'
and not exists(select 1 from dbo.smalltable c where c.source=l.source)

上述查询在三秒内完成。

如果上面的查询返回任何值，我们希望存储过程退出，因此我将其重写如下：

If Exists(
select databasename 
from somedb.dbo.bigtable l where databasename ='someval' and source  <>'kt'
and not exists(select 1 from dbo.smalltable c where c.source=l.source)
)
Begin
Raiserror('Source missing',16,1)
Return
End

但是，这需要 10 分钟。

我可以像下面这样重写上面的查询，它也可以在不到 3 秒的时间内完成：

  select databasename 
from somedb.dbo.bigtable l where databasename ='someval' and source  <>'kt'
and not exists(select 1 from dbo.smalltable c where c.source=l.source
if @@rowcount >0 …

我有一个宽表，相对较大，有 14,264,775 行，在 Azure SQL 数据库上运行。

以下查询需要一些 TLC。

IF EXISTS (
    SELECT  1/0 
    FROM dbo.table1 src
      INNER JOIN dbo.table1 tgt 
        ON tgt.Col1 = src.Col1
    WHERE tgt.ValidFrom <= src.ValidTo
    AND tgt.ValidTo >= src.ValidFrom
    AND tgt.RecordId <> src.RecordId  
)
 BEGIN
    RAISERROR('Overlap detected in dbo.table1', 11, 1); 
 END ;

我有这个索引。

CREATE NONCLUSTERED INDEX [IX__table1] ON dbo.table1
        ( Col1 ) 
INCLUDE (ValidFrom, ValidTo, RecordId)
GO

这是查询的 io 统计信息。逻辑阅读能力非常出色。

这是计划 XML。我尝试了 PasteThePlan，但它无法解析计划 XML。（也许它不喜欢Axure sql数据库计划xml）。

如您所见，[src] 上有一个索引扫描；读取 14,264,775 行（与表中的所有行数相同）。并在 [tgt] 上进行索引查找；读取 194,405,307 行。

我需要改变什么来提高查询的性能？ …