本文属于Azure SQL DB/DW系列
上一文：Azure SQL DB/DW 系列（8）——重新认识Query Store（1）——简介
本文介绍Query Store的技术内幕
数据来源
Query Store中的数据由三个部分的数据来源组成：
- 查询和计划的信息：有关查询本身的数据以及查询优化器从该查询派生的执行计划的数据。
- 查询的运行时信息：查询运行得多快，被调用了多少次，以及在运行的时候性能相关信息。
- 查询的等待信息：收集查询在运行时的相关等待信息。
收集查询和计划的信息
当一个查询（不仅限于SELECT）提交到SQL Server时，会经过一系列的处理过程，这些过程包括校验SQL及需要用到的对象，但是最重要的就是进行优化，并且尽可能快地生成执行计划，同时执行计划也要是足够优秀的。大概流程如下：
Query Store仅收集DML信息，这些DML包括SELECT/UPDATE/DELETE/INSERT等，而DDL是不会被收集的。至少目前不会。
再看下图，当查询被编译和分析优化后生成了执行计划，就会有一个异步的过程获取查询和执行计划的信息发给Query Store。这个过程首先会把信息临时存放在内存中，然后在一定间隔（Query Store中可定义）后再异步写到磁盘。这一方面是为了减轻过多实时操作对服务器的压力，另外一方面是减少对优化过程的干预。不过有个例外，就是强制计划，这个过程会干扰正常的优化过程，如果查询已经应用了计划强制，那么会把强制后的计划写到缓存中，而不是由优化器产生的执行计划。
这个过程是独立的语句级别的，不是基于存储过程或者批。如果查询是属于某个对象（存储过程、批），那么对象的ID也会带进收集的信息里面。
收集查询的运行时和等待信息
在获取了执行计划之后，就会收集运行时的统计信息和等待信息，当然，只有在真正运行的时候才会产生这些信息，也就是说在运行的时候才会收集。这些数据会存在内存中大概15分钟，才会写到磁盘。
在收集了一次信息之后，因为重编译导致重新生成执行计划。如果跟Query Store中的一样，那么只会更新统计信息。如果因为重编译产生新的执行计划，那么新的执行计划也会被捕获到Query Store中。
因为收集的数据先到内存再到磁盘，所以可能会出现异常丢失，比如服务器被重启或者内存被清空。你可以手动使用sys.sp_query_store_flush_db来刷到磁盘。
读者可能会觉得为什么要把看上去是一起查询的运行时和等待信息分开收集，因为Query Store从2016出现，在2016和2017时才加入了等待的统计信息，所以当时需要分开来看。另外这两个信息虽然收集的时间接近一致，但是很多时候分析是需要分开的。
接下来我们进入更加深入的介绍。
查询和查询计划信息
这部分的信息，可以从下面四个目录视图中获取：
- sys.query_context_settings：关于查询运行的上下文配置。
- sys.query_store_query：这是关系中最核心的部分，把其他三个目录视图连接起来。
- sys.query_store_query_text：存储了查询的文本信息。
- sys.query_store_plan：这个视图存储了查询的执行计划，通过外键query_id和sys.query_store_query关联。
它们之间的关系如图，在后面文章中会一边介绍一边演示。
运行时信息
涉及的目录视图有：
sys.query_store_runtime_stats通过plan_id和runtime_stats_interval_id和其他两个表关联。其实从这些表关系中我们也可以学习一些数据库设计的理念。
sys.query_store_runtime_stats有很多我们感兴趣的列，比如duration（持续时间），CPU time，行数，内存等。
sys.query_store_runtime_stats_interval这个视图中，execution_type会影响信息的收集，它有三个值：0——成功执行；3——用户终止执行；4——意外终止执行。
等待统计信息
目录视图的关系如下：
和运行时信息一样，他们是按照运行时间隔来汇总数据。同时和运行时信息一样每15分钟刷一次内存数据到磁盘中。
总结
本文介绍了Query Store的三个组成部分，通过这三个部分，查询的运行情况被分开来收集和存储。