（点击上方蓝字，快速关注我们)
简介 我们平时所写的SQL语句本质只是获取数据的逻辑，而不是获取数据的物理路径。当我们写的SQL语句传到SQL Server的时候，查询分析器会将语句依次进行解析（Parse）、绑定（Bind）、查询优化（Optimization，有时候也被称为简化）、执行（Execution）。除去执行步骤外，前三个步骤之后就生成了执行计划，也就是SQL Server按照该计划获取物理数据方式，最后执行步骤按照执行计划执行查询从而获得结果。但查询优化器不是本篇的重点，本篇文章主要讲述查询优化器在生成执行计划之后，缓存执行计划的相关机制以及常见问题。 为什么需要执行计划缓存从简介中我们知道，生成执行计划的过程步骤所占的比例众多，会消耗掉各CPU和内存资源。而实际上，查询优化器生成执行计划要做更多的工作，大概分为3部分：
上面三个步骤完成之后，才会生成多个候选执行计划。虽然我们的SQL语句逻辑上只有一个，但是符合这个逻辑顺序的物理获取数据的顺序却可以有多条，打个比方，你希望从北京到上海，即可以做高铁，也可以做飞机，但从北京到上海这个描述是逻辑描述，具体怎么实现路径有多条。那让我们再看一个SQL Server中的举例，比如代码清单1中的查询。
代码清单1. 对于该查询来说，无论A先Inner join B还是B先Inner Join C，结果都是一样的，因此可以生成多个执行计划，但一个基本原则是SQL Server不一定会选择最好的执行计划，而是选择足够好的计划，这是由于评估所有的执行计划的成本所消耗的成本不应该过大。最终，SQL Server会根据数据的基数和每一步所消耗的CPU和IO的成本来评估执行计划的成本，所以执行计划的选择重度依赖于统计信息，关于统计信息的相关内容，我就不细说了。 对于前面查询分析器生成执行计划的过程不难看出，该步骤消耗的资源成本也是惊人的。因此当同样的查询执行一次以后，将其缓存起来将会大大减少执行计划的编译，从而提高效率，这就是执行计划缓存存在的初衷。 执行计划所缓存的对象执行计划所缓存的对象分为4类，分别是：
比如说我们可以通过dm_exec_cached_plans这个DMV找到被缓存的执行计划，如图1所示。 图1.被缓存的执行计划 那究竟这几类对象缓存所占用的内存相关信息该怎么看呢？我们可以通过dm_os_memory_cache_counters这个DMV看到，上述几类被缓存的对象如图2所示。 图2.在内存中这几类对象缓存所占用的内存 另外，执行计划缓存是一种缓存。而缓存中的对象会根据算法被替换掉。对于执行计划缓存来说，被替换的算法主要是基于内存压力。而内存压力会被分为两种，既内部压力和外部压力。外部压力是由于Buffer Pool的可用空间降到某一临界值（该临界值会根据物理内存的大小而不同，如果设置了最大内存则根据最大内存来）。内部压力是由于执行计划缓存中的对象超过某一个阈值，比如说32位的SQL Server该阈值为40000，而64位中该值被提升到了160000。
基于被缓存的执行计划对语句进行调优被缓存的执行计划所存储的内容非常丰富，不仅仅包括被缓存的执行计划、语句，还包括被缓存执行计划的统计信息，比如说CPU的使用、等待时间等。但这里值得注意的是，这里的统计只算执行时间，而不算编译时间。比如说我们可以利用代码清单2中的代码根据被缓存的执行计划找到数据库中耗时最长的20个查询语句。
|
注册
登录
