SQL Server性能调优之执行计划深度剖析第一节—浅析SQL执行的过程

前言：在SQL Server中，执行计划在查询过程中其中关键性的作用，也是数据库性能调优的重要方面，为优化提供了很多的数据依据。本系列文章前前后后会有几十篇，将会对执行计划进行深入浅出的讲述，并且也会讲述如何利用执行计划进行数据库调优。
 
本篇文章的议题如下：
查询计划概述
查询解析
查询优化器
查询执行
查询计划的重用
查询计划概述
 
    很多时候，当我们在使用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语句生成成本最低的执行计划。
 
    另外，我们来归对于优化器所用到的统计数据进行简要的解析。所谓的统计数据，就是在数据库中描述列、索引相关信息的数据，即数据的数据，或称之为“元数据”。优化器就是结合统计数据和查询处理树来进行成本的估计的。
 
    在默认的情况下，统计信息是由数据库内部自动的进行更新的（在调优的时候，可以手动的更新）。
 
    需要提及的就是：表变量是没有任何的统计数据的，也就是说，如果对表变量中的数据进行查询，优化器