SQL Server性能调优之执行计划深度剖析 第一节 浅析SQL执行的过程
前言：在SQL Server中，执行计划在查询过程中其中关键性的作用，也是数据库性能调优的重要方面，为优化提供了很多的数据依据。本系列文章前前后后会有几十篇，将会对执行计划进行深入浅出的讲述，并且也会讲述如何利用执行计划进行数据库调优。
为了使得大家更好的理解、消化这些知识，我会定期的就所写内容进行在线的视频讲座，朋友们可以去参与这个小组：http://www.agilesharp.com/c/sqlprofiler.aspx
本篇文章的议题如下：
- 查询计划概述
- 查询解析
- 查询优化器
- 查询执行
- 查询计划的重用
查询计划概述
很多时候，当我们在使用sql server的时候，做的事情非常简单：输入sql语句，然后执行，最后获取结果。下面，为了使得大家更加清楚的了解Sql server的内部机制，我们就重新来审视一个sql语句的执行。
把sql语句提到给了之后，数据库会执行一系列的内部处理，我们大致的可将内部的处理按照执行的顺序，划分为两个阶段：
1. 发生在关系引擎中的操作
2. 发生在存储引擎中的操作
在数据库的关系引擎中，sql 的查询语句会解析并且将解析的结果传递给后面的查询优化器，查询优化器负责生成执行计划。之后，执行计划（以二级制的格式）就会被传递到存储引擎里面，最后返回或更新底层的数据。
数据库的存储引擎会进行很多的操作，例如锁定，索引的维护，事务的处理等。
因为本系列文章主要的剖析执行计划，所以我们的关注点会放在关系引擎上面。
下面，我们就来稍微详细的讨论一个sql查询语句的执行过程。
查询解析
正如我们刚刚提到过：当把一个sql语句提交到了数据库以后，sql语句最先会被传入到关系引擎中。
当sql语句达到了关系引擎之后，首先要进行的操作就是检查sql语句的格式是否正确。这个处理过程就是我们常说的“解析”过程。解析过程的结果就是生成一个解析树，或者称为查询树。查询树反映了一个查询要执行的逻辑步骤，查询树的结构类似下面图中所示：
其实从编译原理的角度来看，这个解析过程就是文法和词法的解析，最后生成语法树。
有一点需要注意的就是：如果提交的sql语句不是一个数据操作语句（数据操作语句指Select，Insert，Update语句），那么这个语句是不会被优化的。例如，如果提交的sql语句是创建一个数据表，那么这个语句是不会被优化的，而是直接执行。
如果提交的数据操作语句，那么之前由关系引擎创建的解析树就会传递给algebrizer组件执行绑定过程。在这个绑定过程过程中，这个algebrizer组件就会去检查解析树中的表名，列名是否都关联到了数据库中相应的表或对象的引用。
同时，algebrizer组件还负责确定解析树中的每个节点的类型是否和数据库中对应的是否一致。algebrizer组件以从下到上的方式开始遍历树，即，先从页级节点开始，也就是列和常量。
绑定解析是一个非常重要的过程，在这个过程中还会识别出我们自己定义的一些别名。这个过程执行完成之后，就会产生一个二进制的“查询处理树”，这个树会被传递给查询优化器。
查询优化器
查询优化器使用查询处理树和相关的统计信息来生成一个执行计划。
换句话说，查询优化器指出了如何最好的去执行提交的sql语句。查询优化器会决定是否可以采用索引来访问数据，采用那种类型的join操作会更好（例如，尽管我们有时候在sql中写的是Left Join，可能查询优化器在分析之后，在保证结果一样的前提下，采用Inner Join）。
查询优化器是一个基本成本分析的优化器。这意味着它会尝试为每个sql语句生成成本最低的执行计划。
另外，我们来归对于优化器所用到的统计数据进行简要的解析。所谓的统计数据，就是在数据库中描述列、索引相关信息的数据，即数据的数据，或称之为“元数据”。优化器就是结合统计数据和查询处理树来进行成本的估计的。
在默认的情况下，统计信息是由数据库内部自动的进行更新的（在调优的时候，可以手动的更新）。
需要提及的就是：表变量是没有任何的统计数据的，也就是说，如果对表变量中的数据进行查询，优化器是不做任何的优化的。但是临时表是有相应的统计数据的。
有一点需要注意的就是：上面的成本只是“估算”而已。一些复杂的语句可能会有很多个候选的执行计划，在这种情况下，查询优化器不会分析所有的组合，而是找出一个接近理论最小值的一个执行计划。计划的成本表现为估计完成查询所需的时间。最低估计成本不一定是最低的资源成本。
查询执行
一旦执行计划生成之后，操作就转入存储引擎中，这也是查询真正被执行的地方，也是根据估计执行计划 产生实际执行计划的产所。
查询计划的重用
从之前的一些步骤可以看到：Sql Server产生一个实际的执行计划需要很多的步骤和很多的成本（执行计划的过度编译往往成为一个很大的性能问题），必须尽可能的重用执行计划（如果后文不做特殊说明，执行计划就指代“实际执行计划”），所以，在数据库中，一旦执行计划产生之后，就被缓存在了内存中（称之为计划缓冲）。
正如之前所提到的，当优化器产生了估计的执行计划之后，计划就会被传递给存储引擎。其实在将估计的执行计划传给存储引擎之前，查询优化器就去“计划缓冲”中查找与现在估计的执行计划对应的实际执行计划。如果找到了，那么，查询优化器将会使用执行计划传进行后续操作。这样就避免了重新生成实际的执行计划。
一般而言，每个查询的执行计划都只保存一个，除非查询优化器知道采用并行执行可以产生更好的性能，此时，并行查询的执行计划就被缓存起来，也就是说：同一个查询，在计划缓冲中有两个执行计划。
执行计划并不是永远被保存在内存中的。它们也是会过期的。SQL Server会基于最近最少使用的算法来移除那些不常用的执行计划。下面列出了执行计划被移除的几个条件：
1. 系统产生了内存压力，需要更多的内存，此时迫使SQL Server释放自己占用的内存。
2. 内存中的执行计划的最近使用次数为0.
3. 执行计划没有被现在的数据库连接引用。
注:熟悉.NET的朋友，可以将之与.NET的垃圾回收机制类比理解。
今天就到这里，下一篇，我们将对执行计划进行更多的分析！
更多文章尽在：首发：IT创业互推平台 www.agilesharp.com