5

为什么此查询在 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 行。

我可以使用提示声明 SQL Server 优化器使其正确吗？ 执行计划

4

2 回答 2

3

我看到你现在已经发布了计划。只是抽奖的运气。

您的实际查询是 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

无论是好计划还是坏计划，执行计划都将“提前终止语句优化的原因”显示为“超时”。

这两个计划的加入顺序略有不同。

计划中唯一不满足索引搜索的连接是 on Tab9。这有 63,926 行。

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

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

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

糟糕的计划

SQL Server 估计将返回 1.349174 行，这些行将从之前进入 join on 的连接中返回Tab9。因此，嵌套循环连接的成本就好像它需要对内部表执行 1.349174 次扫描一样。

事实上，有 2,600 行输入到该连接中，这意味着它对Tab9（2,600 * 63,926 = 164,569,600 行）进行了 2,600 次完整扫描。

碰巧的是，在好的计划中，估计进入连接的行数是 2.74319。这仍然是三个数量级的错误，但略微增加的估计意味着 SQL Server 更倾向于使用哈希连接。哈希连接只做一次通过Tab9

好计划

我会首先尝试在Tab9.

此外/相反，您可以尝试更新所有相关表的统计信息（尤其是那些带有日期谓词的表Tab2 Tab3 Tab7 Tab8 Tab6），看看这是否有助于纠正计划左侧估计行与实际行之间的巨大差异。

此外，将查询分解成更小的部分并将它们具体化为具有适当索引的临时表可能会有所帮助。SQL Server 然后可以使用这些部分结果的统计信息来为计划中稍后的连接做出更好的决策。

只有作为最后的手段，我才会考虑使用查询提示来尝试强制执行带有哈希连接的计划。您的选择是USE PLAN提示，在这种情况下，您可以准确地指定您想要的计划，包括所有连接类型和顺序，或者通过说明LEFT OUTER HASH JOIN tab9 ...。第二个选项还具有修复计划中所有连接顺序的副作用。两者都意味着 SQL Server 将受到严重限制的是它根据数据分布的变化调整计划的能力。

于 2013-03-17T19:16:37.903 回答
1

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

于 2013-03-15T17:37:28.363 回答