Question

为什么SQL Server 2008 R2（版本10.50.2806.0）中的查询速度更快

    SELECT
        MAX(AtDate1),
        MIN(AtDate2)
    FROM
    (
        SELECT TOP 1000000000000
            at.Date1 AS AtDate1,
            at.Date2 AS AtDate2
        FROM
            dbo.tab1 a
        INNER JOIN
            dbo.tab2 at
        ON
            a.id = at.RootId
        AND CAST(GETDATE() AS DATE) BETWEEN at.Date1 AND at.Date2
        WHERE
            a.Number = 223889
    )B

然后

    SELECT
        MAX(AtDate1),
        MIN(AtDate2)
    FROM
    (
        SELECT 
            at.Date1 AS AtDate1,
            at.Date2 AS AtDate2
        FROM
            dbo.tab1 a
        INNER JOIN
            dbo.tab2 at
        ON
            a.id = at.RootId
        AND CAST(GETDATE() AS DATE) BETWEEN at.Date1 AND at.Date2
        WHERE
            a.Number = 223889
    )B

TOP属性的第二个语句快六倍。

内部子查询的count(*)是9280行。

我可以使用HINT声明SQL Server优化器是否正确？ execution plan

Answer 1

我看到你现在发布了the plans。只是运气好运。

您的实际查询是16个表连接。

SELECT max(atDate1)  AS AtDate1,
       min(atDate2)  AS AtDate2,
       max(vtDate1)  AS vtDate1,
       min(vtDate2)  AS vtDate2,
       max(bgtDate1) AS bgtDate1,
       min(bgtDate2) AS bgtDate2,
       max(lftDate1) AS lftDate1,
       min(lftDate2) AS lftDate2,
       max(lgtDate1) AS lgtDate1,
       min(lgtDate2) AS lgtDate2,
       max(bltDate1) AS bltDate1,
       min(bltDate2) AS bltDate2
FROM   (SELECT TOP 100000 at.Date1  AS atDate1,
                          at.Date2  AS atDate2,
                          vt.Date1  AS vtDate1,
                          vt.Date2  AS vtDate2,
                          bgt.Date1 AS bgtDate1,
                          bgt.Date2 AS bgtDate2,
                          lft.Date1 AS lftDate1,
                          lft.Date2 AS lftDate2,
                          lgt.Date1 AS lgtDate1,
                          lgt.Date2 AS lgtDate2,
                          blt.Date1 AS bltDate1,
                          blt.Date2 AS bltDate2
        FROM   dbo.Tab1 a
               INNER JOIN dbo.Tab2 at
                 ON a.id = at.Tab1Id
                    AND cast(Getdate() AS DATE) BETWEEN at.Date1 AND at.Date2
               INNER JOIN dbo.Tab5 v
                 ON v.Tab1Id = a.Id
               INNER JOIN dbo.Tab16 g
                 ON g.Tab5Id = v.Id
               INNER JOIN dbo.Tab3 vt
                 ON v.id = vt.Tab5Id
                    AND cast(Getdate() AS DATE) BETWEEN vt.Date1 AND vt.Date2
               LEFT OUTER JOIN dbo.Tab4 vk
                 ON v.id = vk.Tab5Id
               LEFT OUTER JOIN dbo.VerkaufsTab3 vkt
                 ON vk.id = vkt.Tab4Id
               LEFT OUTER JOIN dbo.Plu p
                 ON p.Tab4Id = vk.Id
               LEFT OUTER JOIN dbo.Tab15 bg
                 ON bg.Tab5Id = v.Id
               LEFT OUTER JOIN dbo.Tab7 bgt
                 ON bgt.Tab15Id = bg.Id
                    AND cast(Getdate() AS DATE) BETWEEN bgt.Date1 AND bgt.Date2
               LEFT OUTER JOIN dbo.Tab11 b
                 ON b.Tab15Id = bg.Id
               LEFT OUTER JOIN dbo.Tab14 lf
                 ON lf.Id = b.Id
               LEFT OUTER JOIN dbo.Tab8 lft
                 ON lft.Tab14Id = lf.Id
                    AND cast(Getdate() AS DATE) BETWEEN lft.Date1 AND lft.Date2
               LEFT OUTER JOIN dbo.Tab13 lg
                 ON lg.Id = b.Id
               LEFT OUTER JOIN dbo.Tab9 lgt
                 ON lgt.Tab13Id = lg.Id
                    AND cast(Getdate() AS DATE) BETWEEN lgt.Date1 AND lgt.Date2
               LEFT OUTER JOIN dbo.Tab10 bl
                 ON bl.Tab11Id = b.Id
               LEFT OUTER JOIN dbo.Tab6 blt
                 ON blt.Tab10Id = bl.Id
                    AND cast(Getdate() AS DATE) BETWEEN blt.Date1 AND blt.Date2
        WHERE  a.Nummer = 223889) B

在好的和坏的计划中，执行计划将“提前终止报表优化的原因”显示为“超时”。

这两个计划的联接订单略有不同。

在Tab9上，索引搜索不满足的计划中唯一的加入。这有63,926行。

执行计划中缺少的索引详细信息表明您创建了以下索引。

CREATE NONCLUSTERED INDEX [miising_index]
ON [dbo].[Tab9] ([Date1],[Date2])
INCLUDE ([Tab13Id])

可以在SQL Sentry Plan Explorer中清楚地看到错误计划中有问题的部分

Bad Plan

SQL Server估计将从Tab9进入联接的先前联接返回1.349174行。因此，嵌套循环连接的成本就好像它需要在内部表上执行扫描1.349174次。

实际上有2,600行进入该连接，意味着它完成了Tab9的2,600次全扫描（2,600 * 63,926 = 164,569,600行。）

恰好在好的计划中，进入连接的估计行数是2.74319。这仍然是错误的三个数量级，但略微增加的估计意味着SQL Server更喜欢散列连接。哈希联接只需通过Tab9

Good Plan

我首先尝试在Tab9上添加缺失的索引。

另外/您可能会尝试更新所有相关表格的统计信息（特别是那些带有日期谓词的表格，例如Tab2 Tab3 Tab7 Tab8 Tab6 ）看看是否有某种方法可以纠正计划左侧估计行与实际行之间的巨大差异。

同样将查询分解为更小的部分并将这些部分实现为具有适当索引的临时表可能会有所帮助。然后，SQL Server可以使用这些部分结果的统计信息来为计划中的联接做出更好的决策。

仅作为最后的手段，我会考虑使用查询提示来尝试使用散列连接强制计划。您执行此操作的选项可以是USE PLAN提示，在这种情况下，您可以准确地指定所需的计划，包括所有联接类型和订单，或者说明LEFT OUTER HASH JOIN tab9 ...。第二个选项还具有修复计划中所有连接订单的副作用。两者都意味着SQL Server将受到严格限制，因为它能够根据数据分布的变化来调整计划。

Answer 2

很难回答不知道表的大小和结构，也无法看到整个执行计划。但两个计划的区别在于“前n”查询的哈希匹配加入与另一个查询的嵌套循环加入。散列匹配是非常耗费资源的连接，因为服务器必须准备散列桶才能使用它。但是对于大表来说它变得更有效，而嵌套循环，将一个表中的每一行与另一个表中的每一行进行比较对于小表来说非常有用，因为不需要这样的准备。我认为通过在子查询中选择TOP 1000000000000行，您可以为优化器提示您子查询将产生大量数据，因此它使用Hash Match。但实际上输出很小，因此嵌套循环效果更好。我刚才所说的是基于信息的碎片，所以请批评我的回答;）。

使用top属性更快地查询

2 个答案: