小编Pau*_*ulM的帖子

我试图找出上周遇到的一种情况，为了临时修复事件期间的计划回归，我使用查询存储强制执行计划，但发现它没有按预期工作。我已经阅读了安德鲁凯利关于如何被迫并不总是意味着被迫的文章，并认为这可能是我所看到的，但我希望对它有更深入的了解，因为在我的情况下，计划与我不同” 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 *会导致大内存授予，因为它是一个宽表，但我主要是想了解这里看到的查询存储行为，以及在较小程度上，为什么在使用而不是强制的计划中计划它使用不同的索引并且必须进行排序。 …