对于多数开发者来说,一旦出现性能方面的回归缺陷,通常可以追溯到某个特殊的事件,例如用户的大量涌入或代码的变更。而对数据库开发者来说,事情就没有那么简单了。随着索引的重建与统计数据的更新,SQL Server 或许会决定“重写”你的代码,重新生成执行计划。如果找不到正确的备份以及与生产环境同等级别的硬件,想了解执行计划中的变更基本上是不可能的,至少目前来说是这样。
而在SQL Server 2016 中,微软将通过一个名为 Query Store 的特性对执行计划的历史变动进行保存。一旦启用了 Query Store,它就会将每个查询中的信息进行日志记录,包括:
- 执行次数
- 执行时间
- 内存占用
- 逻辑读取
- 逻辑写入
- 物理读取
- 执行计划变更次数
为了减少对服务器的压力,这些信息是按照固定的时间窗口进行聚合的。如果你需要更详细的数据,应转而使用扩展事件(Extended Events)特性。
要查看这些信息,最简单的方式是直接打开回归查询(Regressed Queries)视图。
在这个工具中,你可以根据任意一种记录的指标查看回归缺陷。当你找到回归缺陷之后,可以选择强制 SQL Server 使用之前的执行计划。
对 Query Store 进行微调
由于对这些指标的跟踪可能会带来很大的开销,因此 SQL Server 允许你对 Query Store 进行微调。可调整的因子包括聚合时间窗口的长度(单位为分钟)、Query Store 的最大体积(单位为 MB),以及可保存的执行计划的最大数量。你还可以让 Query Store 只记录满足特定条件的查询。
通过编程方式进行访问
与大多数 SQL Server 特性一样,在回归查询工具中所能看到的全部信息都能够通过使用一系列管理视图进行直接访问。
- sys.database_query_store_options (Transact-SQL)
- sys.query_context_settings (Transact-SQL)
- sys.query_store_plan (Transact-SQL)
- sys.query_store_query (Transact-SQL)
- sys.query_store_query_text (Transact-SQL)
- sys.query_store_runtime_stats (Transact-SQL)
- sys.query_store_runtime_stats_interval (Transact-SQL)
查看英文原文: SQL Server 2016: Identify Regressions with Query Store
评论