这解释起来有点复杂,但很容易重现。
对于大约 10%-30% 的查询(按计数),大量的查询存储数据不可用。我查看了 SQL 2016 和 SQL 2017,其中查询存储已经运行了数周以上,数据库上有活动。
下面的查询将返回两组数据,顶部集没有 值query_store_query.last_execution_time,而底部集在字段中有数据。“没有”也缺少大多数运行时统计数据。
EXEC sp_query_store_flush_db; --Same results without this, but just to rule it out in the examples.
go
Select * from sys.query_store_query
where query_store_query.last_execution_time is null -- there are bunch of these, also missing other data, why?
Select * from sys.query_store_query
where query_store_query.last_execution_time is not null
Run Code Online (Sandbox Code Playgroud)
我最初使用导出的查询存储数据发现了这一点我的数据在 Excel 工作表中,我进行了排序和比较,但没有发现任何将“拥有”与“没有”分开的共同因素
为了排除数据导出问题,我使用上面的代码直接从系统数据视图中获取数据。结果与导出数据中的结果相似。
为了排除系统数据视图,我使用“跟踪查询”从根数据报告。(查询存储 > 跟踪查询 > 配置)
3.A. 对于“拥有”,查询计划等会显示出来,正如您所期望的
3.B. 对于“没有”,没有查询计划和指标
我发现的唯一范围限制因素是,在非常活跃的数据库上,“没有”仅限于最后几个小时。但是在慢速数据库上,“没有”可能有可以追溯到几周前的 initial_compile_start_time。(我怀疑“没有”正在被清除,然后在下次运行“以前从未见过,新”查询时重新创建)
“没有”可以有任何范围的编译计数、计划数量等。
我的 SQL Server 有时会报告大量的延迟写入。例如“每秒延迟写入为 119 次写入/秒”