Question

下面是我可能运行的查询示例，对于每个类别，我希望NumberOfCourses不仅代表该特定类别，还代表其下的任何子类别。我认为查询是相当自我解释的。

select  c.CategoryID, courses.MarketID, count(distinct courses.CourseID) NumberOfCourses
from    Category c
        join CategoryHierarchy tch on tch.HierarchyKey like '%~' + cast(c.CategoryID as varchar) + '~%'
        join vLiveEvents courses on tch.CategoryID = courses.CategoryID
where   courses.MarketID is not null
group by c.CategoryHumanID, courses.MarketID

当我按原样运行时，可能需要将近两分钟，但是如果我添加提示Option (Force Order)，则只需几秒钟即可运行。所以我的问题是我做错了导致SQL创建错误的计划，还是SQL引擎实际上并不擅长优化这样的层次结合？

我尝试了包含sql计划，但它太长了，所以不会让我拥有那么多角色。如果有人能告诉我怎么做，我很乐意分享它。

编辑：我想可能不是每个人都知道这些层次结构是如何工作的。它们的层次结构键看起来像~1234~5678~9123~其中1234是5678的父节点，它是9123的父节点。通过对CategoryID进行类似的比较，我可以在结果中包括所有子类别。

Answer 1

从SQL Server 2016+开始，引入了Query Store功能来监控性能。它提供了对查询计划选择和性能的深入了解。

它还提供强制计划的选项。

它不是跟踪或扩展事件的完全替代，但随着它从版本到版本的发展，我们可能会在SQL Server的未来版本中获得一个功能齐全的查询存储。 Query Store的主要流程

SQL Server现有组件使用Query Store Manager与查询存储进行交互。
查询商店管理器确定应使用哪个商店，然后将执行传递到该商店（计划或运行时统计信息或查询等待统计信息）
- 计划商店 - 保留执行计划信息
- 运行时统计信息存储 - 保留执行统计信息
- 查询等待统计信息存储 - 保留等待统计信息。
计划，运行时统计信息和等待存储使用“查询存储”作为SQL Server的扩展。

启用查询存储：查询存储在服务器上的数据库级别工作。
- 默认情况下，查询存储对新数据库不起作用。
- 您无法为主数据库或tempdb数据库启用查询存储。
- 可用的DMV
  
  sys.database_query_store_options（Transact-SQL）
在查询商店中收集信息：我们使用Query Store DMV（数据管理视图）从三家商店收集所有可用信息。
- 查询计划商店 保留执行计划信息，并且它负责捕获与查询编译相关的所有信息。
  
  sys.query_store_query（Transact-SQL） sys.query_store_plan（Transact-SQL） sys.query_store_query_text（Transact-SQL）
- 运行时统计信息存储 保留执行统计信息，它可能是最频繁更新的商店。这些统计信息表示查询执行数据。
  
  sys.query_store_runtime_stats（Transact-SQL）
- 查询等待统计信息存储 持久化和捕获等待统计信息。
  
  sys.query_store_wait_stats（Transact-SQL）

注意：查询等待统计信息存储仅在SQL Server 2017 +

为什么我必须使用这些层次结构查询强制订单/

1 个答案: