了解查询存储不遵守强制计划时的计划选择

Question

我试图找出上周遇到的一种情况，为了临时修复事件期间的计划回归，我使用查询存储强制执行计划，但发现它没有按预期工作。我已经阅读了安德鲁凯利关于如何被迫并不总是意味着被迫的文章，并认为这可能是我所看到的，但我希望对它有更深入的了解，因为在我的情况下，计划与我不同” d 期待。我还查看了有关计划强制的查询存储文档的计划强制限制部分，但我认为此处不适用任何限制。

查询存储中的视图如下所示 - 大约 8:30 出现了一个成本更高的新计划（2.14178 vs 0.894238），我强制执行了之前使用的计划。从图中可以看出，尽管我强制执行了旧计划，但从此时起，新计划将针对查询的指标显示：

查看 sys.query_store_plan，我可以看到旧计划显示为强制的并且没有任何反对意见，表明强制执行失败：

奇怪的是，当我后来查看计划缓存时，这些计划都没有使用，尽管使用中的计划确实具有与上面显示的计划 13449 相同的查询计划哈希值，尽管它们完全不同。实际使用的计划的估计成本要高得多，为 72.6743。

我从这些计划中的每一个中获取了编译值，并运行了对其中三个计划的查询，以了解计划的实际指标是什么样的，并且这些值与估计值大不相同。值得注意的是，我从缓存中获取的计划产生了大约 400 MB 的内存授予，因为它使用不同的索引并且必须对数据进行排序，而其他 2 个计划中的 8 MB 内存授予没有排序。三个计划的估计成本更接近一些，但查询存储中的 2 个计划的估计成本比查询存储中显示的计划高得多。

这是发生的查询：

(
    @id_group int,
    @create_date datetime,
    @rows_per_page int,
    @page_number int
)
SELECT *
FROM ts_customer
WHERE 
    id_group = @id_group 
    AND enabled = 'Y'
    AND (create_date >= @create_date)
ORDER BY 
    full_name, 
    id_customer desc
offset 
    ((@page_number - 1) * @rows_per_page) rows
    fetch next @rows_per_page rows only

谁能帮助我理解为什么不强制执行该计划，以及为什么正在使用的计划要贵得多？

我知道这select *会导致大内存授予，因为它是一个宽表，但我主要是想了解这里看到的查询存储行为，以及在较小程度上，为什么在使用而不是强制的计划中计划它使用不同的索引并且必须进行排序。

发生这种情况的数据库在 Azure SQL DB 上运行，兼容性级别为 140，并使用旧基数估计器。

我附上了所有 3 个估计的计划，以及当我使用每组编译值运行查询时生成的计划。这些可以在这里访问。

Answer 1

谁能帮我理解为什么这个计划不是被迫的

查看计划 XML，计划 ID 6194 是在版本 15.0 上编译的。SQL Server 的700.539 ，而计划 ID 13449 是在版本 15.0 上编译的。900.210。

这两个计划之间唯一值得注意的差异（基数估计除外）是：

计算标量受到行目标的影响（由于隐含的TOPfrom OFFSET / FETCH）：

EstimateRowsWithoutRowGoal="170.008"

并且 NL 连接通过无序预取进行了优化：

<NestedLoops Optimized="true" WithUnorderedPrefetch="true">

看来这些细微的差异导致了您链接到的安德鲁·凯利的文章中描述的问题。该计划本质上是相同的，只有细微的实施差异。格兰特·弗里奇对此进行了如下描述：

有一种相对模糊的情况，即可以使用“道德等效”计划（即在所有核心要素上相同但不一定完全相同）来代替您定义的精确计划。然而，这种情况并不常见。

来自他关于执行计划的免费电子书的第 473 页。

为什么正在使用的要贵这么多？

正在使用的真正昂贵的计划有 4 个额外的列，所以我认为这并没有真正进行同类比较。较高的成本似乎主要是由于使用的参数（因此基数估计较高）造成的。顺便说一句，它是在另一个完全不同的版本上：15.0。1300.566。事情在云中确实发展得很快 =P

这些都是来自以下的“新”专栏SELECT *：

<ColumnReference Database="[app-live-au]" Schema="[dbo]" Table="[ts_customer]" Column="delete_requested_date_utc" />
<ColumnReference Database="[app-live-au]" Schema="[dbo]" Table="[ts_customer]" Column="retention_policy_applied_date_utc" />
<ColumnReference Database="[app-live-au]" Schema="[dbo]" Table="[ts_customer]" Column="retention_policy_type" />
<ColumnReference Database="[app-live-au]" Schema="[dbo]" Table="[ts_customer]" Column="id_portal_user" />

您提供的综合测试均与最新版本的内容一致。