在 SQL 查询存储中设置 flush_interval_seconds 时要考虑什么？

Question

查询存储的大多数设置都相当简单。但尽我所知，最有可能导致性能问题（等待）并且文档最不明确的是flush_interval_seconds

我已阅读Erin Stellato 的 SQL Server 查询存储：默认设置

如果我的存储可以支持它，我也可能会将 DATA_FLUSH_INTERVAL_SECONDS 降低到低于 900 秒（15 分钟）的时间。此设置确定查询存储数据刷新到磁盘的频率。如果每 15 分钟一次，那么如果我的服务器在写入磁盘之前发生崩溃，我可能会丢失 15 分钟的查询存储数据。

微软关于查询存储的最佳实践甚至没有提到它。

Microsoft 的sys.database_query_store_options (Transact-SQL)说（用于内部部署）；

定义定期将查询存储数据刷新到磁盘的周期。默认值为 900（15 分钟）。

以上暗示（可能）查询存储数据保存在内存中，直到发生常规的 15 分钟刷新，然后将其推送/刷新到磁盘

但是 Azure 的文档略有不同。在 Azure SQL 数据库中操作查询存储

指定在刷新到磁盘之前将捕获的运行时统计信息保存在内存中的最长时间（重点是我的）

Azure 描述暗示查询存储数据像普通数据一样定期移动到磁盘，但如果它没有按时间移动，则它会被强制移动到磁盘。

我知道查询存储数据是数据库的一部分，我不清楚日志是仅在数据推送到磁盘时更新还是实时更新。

我不清楚的一些要点可能会影响决定。（也许其中一些应该是单独的问题？）

• 查询存储数据是否写入日志？如果是这样，还原是否能让我们恢复任何尚未推送到磁盘的查询存储数据？

• 如果我有一个 AlwaysOn AG，辅助节点是实时获取查询存储数据还是依赖它实际写入主数据库的磁盘？如果我的查询存储数据在 15 分钟内没有写入主数据库，并且主数据库被拔掉，二级数据库会捕获它吗？

• 查询存储磁盘写入是否会与用户 OLPT 数据发生等待冲突？如果有，它们是什么？

• 更改 flush_interval_seconds 值到底有什么作用？

在我的脑海中，有一个长时间运行的查询使用所有系统资源超过一个小时，查询存储达到 15 分钟刷新间隔，现在它与用户应用程序的资源冲突。我无法弄清楚场景到底是什么以及它如何影响用户应用程序。我如何为我设定的价值证明我的决定？

Answer 1

查询存储数据是否写入日志？如果是这样，还原是否能让我们恢复任何尚未推送到磁盘的查询存储数据？

Query Store 被持久化到磁盘，所以它在崩溃时仍然存在。但是Query Store也是Async，这意味着如果数据没有持久化，同时发生crash，数据就会丢失。但是，如果由于维护例行程序而必须重新启动 SQL Server，您可以使用以下过程强制刷新查询存储：sp_query_store_flush_db。

如果我有一个 AlwaysOn AG，辅助节点是实时获取查询存储数据还是依赖它实际写入主数据库的磁盘？如果我的查询存储数据在 15 分钟内没有写入主数据库，并且主数据库被拔掉，二级数据库会捕获它吗？

辅助副本仅从 PRIMARY 获取查询存储数据。你不能在二级上做强制计划等。由于数据是以异步方式写入的，因此会有数据丢失。

查询存储磁盘写入是否会与用户 OLPT 数据发生等待冲突？如果有，它们是什么？

我不明白您所说的等待冲突是什么意思。在处理 60K 传输/秒的非常繁忙的 OLTP 系统上，我没有看到任何冲突。

更改 flush_interval_seconds 值到底有什么作用？

根据BOL - 定义定期将查询存储数据刷新到磁盘的周期。例如，将内存中的数据自动刷新到磁盘而不是手动运行 sp_query_store_flush_db 的频率。