对于多数开发者来说，一旦出现性能方面的回归缺陷，通常可以追溯到某个特殊的事件，例如用户的大量涌入或代码的变更。而对数据库开发者来说，事情 就没有那么简单了。随着索引的重建与统计数据的更新，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特性一样，在回归查询工具中所能看到的全部信息都能够通过使用一系列管理视图进行直接访问。