简介
从名字来看，Query Store就是查询存储，存储了查询（不仅限于SELECT，还包括 DML 语句如 SELECT、INSERT、UPDATE、DELETE、MERGE 和 BULK INSERT的计划。）的执行信息，供后续分析。它可用于SQL Server（本地版），微软PaaS版本的SQL DB和SQL DW。
在过去，如果数据库卡顿，从出现问题到报告给我，可能已经过了半个小时，当我登录服务器的时候，很有可能现象消失，非常难找原因。后来有一些工具可以把信息自己存到一个实体表，但是如果你做过就知道，特别是存储执行计划，不仅获取慢，而且存储空间极大，我当初的系统，一天的执行计划存到表里大概是200G，比数据库本身还大。显然不现实，也不利于分析。
再后来，有了类似扩展事件和第三方工具来辅助，情况才有所缓解。不过还是不够完善。自从Query Store出现之后，我感觉很多问题都可以迎刃而解。
我们知道分析性能问题的时候，最重要的就是执行计划，Query Store不仅存放，还存放多个执行计划，这种多个执行计划可能由于当时的资源使用率（有可能并行），参数变化（参数嗅探等）导致了同一个SQL 不同的执行计划，这些它都存储。
存储的目的是为了后续分析，所以它也提供了比较多的分析功能。比如按时间分割窗口等。后续会演示。
启用
默认情况下，新的数据库是没有启用Query Store的。所以你需要额外启用。可以使用下面命令开启：
ALTER DATABASE [数据库名] SET QUERY_STORE = ON (OPERATION_MODE = READ_WRITE);
或者在非master/tempdb(Azure SQL DB看不到TempDB)的数据库中右键选择属性：
作用
由于数据库环境的变更，包括对象的变更，还有内存压力等原因，都会导致执行计划只能缓存最新版本，甚至连缓存久一点都不行，为了能够找到过往发生的内容，Query Store会存储尽可能多的执行计划。可以通过自动或手动强制某个执行计划（计划强制）作为特定查询的指定执行计划，从而改变该查询的运行情况。不过并不是一定有用。
执行计划用于分析特定查询的执行情况，而等待统计信息可以从更高层次或者更深入的层次中发现实例级别的问题。过去统计信息主要用于实例级别。而且以累加值为主，从SQL 2017和Azure SQL DB开始，query store已经包含了语句级别维度的统计信息。不过需要启用：
ALTER DATABASE [DBName] SET QUERY_STORE (OPERATION_MODE = READ_WRITE, WAIT_STATS_CAPTURE_MODE = ON)
GO
或者在界面操作;
启用之后，可以用Query Store来：
- 快速查找和修复执行计划
- 在特定时间段查询的执行次数，执行次数是很重要的，对只执行一次的查询，只要没有明显影响，我们一般不会花太多时间去检查。对于执行次数非常多的，哪怕只提升一秒，对系统的整体性能而言都是有帮助的。
- 在过去某几个小时内的前n个查询（按资源消耗等排序）
- 分析特定资源的使用情况。
- 确定等待资源的前n个查询。（这个很多工具都能做，不过集成在一起还是好的）
- 查看特定查询的执行计划的等待情况。
Query Store下面又分了三种存储类型：
- 计划存储：用于存储执行计划信息。
- 运行时统计信息存储：用于保存执行过程的统计信息。这个很有价值，毕竟执行过程的数据最能反映问题。
- 等待统计信息存储：用于保存等待统计信息。
Azure SQL DB上的Query Store
上面已经大概浏览了一下通过SSMS找到Query Store，但是其实Azure上的Query Performance Insight也就是上一篇中第二部分，就是以Query Store为基础的。不过基于它的单独存在，所以计划后续再介绍。
我不怎么喜欢过多的理论，虽然我知道非常重要，不过先来看点案例可能能够提起兴趣，接下来的几篇文章我会在SQL Server On Linux 2019上做实验，这样不一定要用到Azure，可以更好地有一个大概的了解。
下一文：Azure SQL DB/DW 系列（4）——Query Store案例（1）