执行计划，简单的说就是查询优化器计算的结果，表示执行被提交查询的效率最高的方式。执行计划告诉你查询是如何被执行的，因此它是DBA诊断低性能查询的基础手段。
1、查询提交后发生了什么
当查询被提交到Sql Server DataBase之后，很多过程就开始工作，最终目的是将数据尽快返回给用户或者存储起来，同时保持数据的一致性。这些过程为每个提交到服务器的查询服务，因而有很多的不同的动作同时发生在服务器上，我们只关注T-SQL相关的事情，粗略的分为两个阶段：
● 关系引擎（relational engine）中发生的过程
● 存储引擎（storage engine）中发生的过程
在关系引擎中，查询优化器解析和处理查询，产生执行计划，然后执行计划被送到存储引擎（二进制方式），存储引擎使用执行计划来获取或更新数据。锁定、索引维护、事物等都发生在存储引擎里头。由于执行计划是由关系引擎产生的，我们将主要关注关系引擎。
1.1 查询解析
T-sql查询到达服务器后去的第一个地方就是关系引擎，它被传递给一个进程来检查拼写和形式，这个处理进程就是查询解析过程。解析过程的输出是一个解析树。解析树代表了执行查询的逻辑步骤。如果T-sql语句不是一个数据操纵语言（DML）声明就不会被优化，举个例子，对于创建table，系统只有一种“正确”的方式，那么就没有机会来提升性能。如果T-sql是DML声明，解析树就被传递给一个叫algebrizer的进程，algebrizer解析查询引用到的所有的对象、表、列的名字，并且识别列的类型（varchar（50） vs nvarchar（25）等），除此之外还要执行一个叫做聚合绑定 的过程来决定聚合的位置。algebrizer进程很重要，因为查询里可能包或了别名、同义词或者不存在的名字，这些需要被解析，或者查询引用了不存在的对象。algebrizer的输出是query processsor tree，二进制形式，然后被传递给了查询优化器。
1.2 查询优化器
查询优化器决定了数据能否访问索引、使用哪种连接还有其他很多东西。这种决定是基于开销的，所需的cpu、io等。查询优化器将会产生并评估很多的计划（除非cache里已经有了），一般来说，选择开销最低的那个，比如运行最快，使用最少的资源、cpu、I/O的那个。执行速度仍然是最重要的因素，如果能够更快返回结果，优化器会选择cpu密集型的过程。有时候优化器也会选择效率较低的计划，如果它认为花时间去评估很多的执行计划还不如采用较低效率的过程。如果你提交了一个非常简单的查询，比方说，单表查询、没有索引、没有聚合、没有计算，那么优化器就不会花时间来计算优化，而是简单的使用trival plan。
如果查询是非Trival的，那么优化器就会计算开销然后选择一个计划。因此它需要依赖sql server服务器维护的统计数据。统计数据是数据库收集的关于列和索引的数据，它描述了数据的分布（distribution）、唯一性（uniqueness）和选择性（selectivity）。构成统计数据的信息使用一个直方图（histogram）和表格（tabulation）来表示，它是从200个平均分布的数据点（data Points）取出来的表示特定数据的出现次数。这种“关于数据的数据”给优化器提供了计算所需的必要信息。
如果列和索引相关的统计数据存在，那么优化器就会使用它们来计算。缺省地，系统会为所有索引和那些用作谓词（predicate）、where子句的一部分、join on子句的一部分的列创建和更新统计数据。Table变量不会产生统计数据，优化器始终假定它只有一行而无视它真正的大小。临时表有统计数据，和永久表的统计数据存储在同一个直方图里供优化器使用。
优化器使用这些统计数据和query processor tree一起决定最佳的执行计划。这就意味着，它需要测试一系列的计划，测试不同的join类型，组织join的顺序，尝试不同的索引等等，直到达成它认为的最快的执行计划。在这个计算中，每一步都赋予了一个数值，代表了优化器预估的时间开销（estimated cost），每一步的开销加起来就是执行计划的开销。
有必要指出，预估的开销毕竟是预估的，如果有无限的时间和完整的最新的统计数据，优化器就能找到执行查询的完美计划，但是优化器是试图在最短的时间找到最佳的执行计划，并且明显的，可用的统计数据的质量也是有限的，因此，虽然这个开销估算是个非常有用的手段，但是不能精确的反映现实。
优化器决定执行计划后，实际的执行计划就被创建并且存储进内存空间plan cache，除非相同的执行计划cache里已经存在。优化器产生可能的执行计划（potential plans），和cache里边已经存在的进行比较，如果匹配就是用cache里边的那个。
1.3 查询执行
执行计划产生后，操作就转移到了存储引擎，在这里根据执行计划实际执行查询。这里不再详细讨论，除了一点，千辛万苦生成的执行计划和设计执行的可能并不一样，比方说一下情景：
● 执行计划超出了并行执行（parallel execution）的界限
● parallel execution 利用多处理器提高执行效率
● 统计数据过期或者发生了改变
