标签: query-store

我在查询存储中强制执行计划。计划与每天运行一次的作业中的过程相关联。这项工作的步骤之一就是：

EXEC [schema].[LoadData]

过程 [schema].[LoadData] 看起来像

TRUNCATE TABLE [schema].[Data];
     
    INSERT INTO [schema].[Data]
           ([A1],
           [A2],
          .
          .
          .,
          [A49]
    )                
    SELECT *
        ,CURRENT_TIMESTAMP AS [Insert TimeStamp] 
    FROM [schema].[View]   

其中 view 是包含一些 CTE 并使用同义词的视图（连接到来自不同数据库的表）。

在查询存储中执行如下所示：

为了测试强制计划是否有效，我按照以下步骤操作：

1. 在 SSMS 中运行查询 ->EXEC [schema].[LoadData]
2. 上面的执行被视为不同的查询，因此在查询存储中没有看到任何新的查询 = 7
3. DBA 仅使用运行查询的步骤创建一个新作业 ->EXEC [schema].[LoadData]
4. 运行上述新创建的作业导致计划 ID = 29800

问题为什么执行计划没有被强制？在“强制计划失败计数”列中为 0。

即使对于相同的查询，计划缓存和查询存储也不相同。当寻找特定查询或一组相关查询的性能或监视信息时，每个查询的优点/缺点是什么？

我的在线研究表明的总体​​印象是，查询存储可以比计划缓存更快地查询（我不确定为什么），并且它的条目往往持续更长时间（这是可配置的），但我没有发现任何说法关于计划缓存优于查询存储的情况。

假设我不关心 SQL Server 2017 和 2022 引入的使用查询存储进行自动性能调优的功能。相反，假设我比较查询存储和计划缓存是出于两者可以执行的任务的目的。

我们正在使用查询存储。现在我们通过每晚清理查询存储解决了一个问题。当您清理查询存储时，查询存储表正在被RESEED编辑 :-(

您知道如何在不RESEED使用表的情况下清理查询存储吗？

我在许多服务器上观察到的 Query Store 运行时统计数据存在这种奇怪的行为，这些行为具有不同的场景，这让我不敢相信这些统计数据。还是我做错了什么？

例如，具有给定查询计划的像这样的琐碎查询：

Stats ( sys.query_store_runtime_stats)max_logical_io_reads在某个偶然的时间间隔报告绝对疯狂的数字：

但是 table 总共只分配了 27 页！

我正在通过跨许多环境的不同查询遇到这种现象。它正在破坏我的回归查询分析。

具有不同读取次数的查询没有不同的计划。

堆表只显示很少更新和插入。巧合的是，我以堆为例。我在使用集群表时也遇到过这种情况。

如果我想知道现在发生了什么，那么我会使用 Adam Machanic 的sp_whoisactive。如果我想了解我的服务器最近发生了什么，那么我将使用查询存储。

扩展事件旨在取代 Profiler，但我认为查询存储的组合sp_whoisactive已经在 2016 或更高版本的任何 SQL Server 上做到了这一点。考虑到这一点，我什么时候会使用扩展事件？

为了获得灵感，我检查了dbatools 附带的扩展事件。我没有留下深刻的印象。它们似乎只对长期监控查询存储不存储的内容有用。例如：某些登录正在执行的操作、锁定、极其特定的 IO 类型、存储过程参数的使用以及已弃用的功能的使用。这些都很好，但坦率地说，我无法想象自己必须在服务器上进行如此外科手术式的调整。有没有我遗漏的常见用法？