主页 / dba / 问题 / 306708
Accepted
SEarle1986
Asked: 2022-01-28 15:11:23 +0800 CST

执行计划中的位图创建导致聚集索引扫描的错误估计

  • 772

鉴于 StackOverflow2010 数据库上的以下简单查询：

SELECT  u.DisplayName,
        u.Reputation
FROM    Users u
        JOIN Posts p
            ON u.id = p.OwnerUserId
WHERE   u.DisplayName = 'alex' AND
        p.CreationDate >= '2010-01-01' AND
        p.CreationDate <= '2010-03-01'

我试图理解为什么要创建索引

CREATE INDEX IX_CreationDate ON Posts
(
    CreationDate
)
INCLUDE (OwnerUserId)

产生更好的估计Posts.CreationDate

当我运行没有索引的查询时，我得到Plan 1。在这个计划中，SQL Server 估计有 298,910 行来自对 Posts 的 CI 扫描，实际上有 552 行回来了——这个估计还有很长的路要走。

添加索引后，我会得到Plan 2，这会导致索引搜索和更准确的估计。

我很好奇为什么添加索引会导致更好的估计，因为在谓词中使用列时会创建统计信息WHERE，无论它是否被索引。

进一步检查，我可以看到Posts.CreationDate计划 1 和计划 2 的谓词不同：

计划 1 谓词

[StackOverflow2010].[dbo].[Posts].[CreationDate] as [p].[CreationDate]>='2010-01-01 00:00:00.000' AND [StackOverflow2010].[dbo].[Posts].[CreationDate] as [p].[CreationDate]<='2010-03-01 00:00:00.000' AND PROBE([Bitmap1002],[StackOverflow2010].[dbo].[Posts].[OwnerUserId] as [p].[OwnerUserId],N'[IN ROW]')

计划 2 谓词

Seek Keys[1]: Start: [StackOverflow2010].[dbo].[Posts].CreationDate >= Scalar Operator('2010-01-01 00:00:00.000'), End: [StackOverflow2010].[dbo].[Posts].CreationDate <= Scalar Operator('2010-03-01 00:00:00.000')

所以我可以看到计划 2 只是要使用直方图来查找两个日期之间的行数，但计划 1 有一个稍微复杂的谓词，涉及位图探测。

这（我认为）解释了为什么对搜索的估计更准确，但我现在想知道什么是位图探测？我可以在计划中看到创建了一个与 Alex 谓词匹配的用户 ID 的位图，这就是正在调查的内容。

我想知道“没有索引，为什么计划 1 与计划 2 不同，唯一的区别是 CI 扫描而不是 CreationDate 上的索引搜索？”

我做了一些进一步的测试，发现如果我在没有索引的情况下运行查询但强制计划进入串行，使用OPTION (MAXDOP 1)我得到计划 3，尽管现在对 Posts 进行 CI 扫描，但它对 CreationDate 的估计更好。如果我查看谓词，我可以看到探针现在已经消失并且位图不再在计划中，因此这使我相信位图与计划并行有关。

所以我的问题是 - 为什么在计划并行时会创建位图，为什么会导致对 的估计如此糟糕Posts.CreationDate？

sql-server execution-plan

1 个回答

  1. Best Answer

    许多因素在起作用：

    该索引带有完整的扫描统计信息。对自动创建的进行采样。

    不同的基数估计模型和执行模式以不同的方式处理计算。在这种情况下，您可能对使用原始 CE 模型的估计更满意：

    USE HINT ('FORCE_LEGACY_CARDINALITY_ESTIMATION')

    位图仅出现在行模式并行计划中。我在Bitmap Magic中写过详细信息（或者……SQL Server 如何使用位图过滤器）

    位图在串行和并行批处理模式计划中都是可能的。您将数据库设置为兼容模式 130，因此行存储上的批处理模式对您不可用。旁注：您可能想要应用 2019 年的最新 CU——您仍在使用 RTM。

    估计公式各不相同，但通常其根源在于使用直方图估计哈希连接的构建端的过滤行和目标表之间的半连接。有时它是一种猜测。有时根本不考虑位图：

    在并行行模式计划中，有两种类型的位图。原始类型的位图是在查询优化完成后启发式添加的。由于它在优化期间不存在，因此对基数估计没有影响。这些位图被命名为Bitmapxxxx. 你的就是其中之一：

    位图

    由于位图的效果与CreationDate谓词混合在一起，因此更难看到。我们可以使用未记录的跟踪标志 9130 将它们分开：

    SELECT
    U.DisplayName,
    U.Reputation
FROM dbo.Users AS U
JOIN dbo.Posts AS P
    ON U.id = P.OwnerUserId
WHERE
    U.DisplayName = N'alex' 
    AND P.CreationDate >= CONVERT(datetime, '2010-01-01', 121)
    AND P.CreationDate <= CONVERT(datetime, '2010-03-01', 121)
OPTION 
(
    USE HINT ('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_130'),
    QUERYTRACEON 9130
);

    位图在扫描时仍然在行内应用，但CreationDate上的谓词在后面的 Filter 运算符中：

    使用 TF 9130 进行扫描估计

    使用 TF 9130 进行滤波器估计

    对扫描的估计是基表的完整基数，尽管位图仍然在那里应用：

    扫描时应用的位图

    如果您有兴趣查看没有位图来比较估计值的计划，您可以启用未记录的跟踪标志 9498。

    第二种类型的行模式位图是所谓的优化位图。这些被评估为基于成本的优化的一部分，因此它们确实对基数估计和最终计划形状有影响。这些位图被命名为Opt_Bitmapxxx.

    我在 SQL Server 的 Batch Mode Bitmaps 中写了有关批处理模式的详细信息。

    • 9

相关问题