概念简介
我们平时所说的查询在SQLServer 中主要有两部分来实现：
- 编译查询，主要包括了五个环节（缓存查找、分析、代数化、优化、缓存新计划）
流程描述： 首先，在计划缓存中查找是否包含新的查询，如果包含则直接交由执行引擎来执行该缓存计划，跳过编译阶段。
其次，如果没有匹配则执行分析阶段（包括参数化、并将SQL文本转化成逻辑树作为下一个阶段的输入），
再次检查缓存后是否包含，包含则交给执行引擎，否则继续下一步。
第三，代数化。
第四，优化并将新计划交给执行引擎。
这里需要有个概念的介绍：执行计划缓存，
SQL Server 有一个用于存储执行计划和数据缓冲区的内存池。池内分配给执行计划或数据缓冲区的百分比随系统状态动态波动。
内存池中用于存储执行计划的部分称为过程缓存。
执行计划缓存主要包含了查询计划和执行上下文。
2. 执行查询计划（生成执行计划--产生查询结果），在下一篇中介绍。
编译和重新编译
SQL Server 有一个高效的算法，可查找用于任何特定 SQL 语句的现有执行计划。SQL Server 将重新使用找到的任何现有计划，从而节省重新编译 SQL 语句的开销。如果没有现有执行计划，SQL Server 将为查询生成新的执行计划。由此我们要做的就是如何高效的应用执行计划的缓存，又在合适重新编译执行计划，来提高查询效率，减少性能的损耗。
首先我们要知道什么情况下会有重新编译产生新的执行计划，我简单总结了几种比较常见的情况：
1.使用WITH REPCOMPILE 或者调用sp_repcompile,将不会缓存计划。
2.架构的变更比如表或试图中添加索引，增加或者删除列等。
如图，当执行架构名称不同的时候会引发重新编译，执行计划缓存不能复用，这个问题需要开发人员注意，经常会有不自觉添加或者减少架构名称的举动。不仅会影响性能，当服务器间移动代码时会引起太多问题，建议使用schema.object(dbo.ExcutionTest)这样的统一规范。
如果是增删索引的话，根据实际情况会生成完全不同的执行计划。如图：
建立索引后有表扫描变为了索引查找，这部分内容我在聚集索引的章节已经有过介绍这里就不详细展开了。
3.SET选项，包括：ANSI_NULLSANSI_WARNINGSCURSOR_CLOSE_ON_COMMIT_INPLICIT_TRANSACTIONSANSI_PADDINGQUOTED_IDENTIFIER,这些选项状态的变化，会引起执行计划的重新编译。建议，尽量采用数据库默认的设置，不要在存储过程中假如不必要的set选项。
4.根据计划的优化程度：如果对键的大量更改（对由查询引用的表使用 INSERT 、UPDATE或 DELETE 语句所产生的修改）。
分析、代数化和优化
1.分析，会将SQL文本转换为逻辑树，为每一个语句创建逻辑树。
2.代数化，主要完成检查语义是否正确。
同时还会完成三个任务：
- 名称解析：查询每个对象的名称是否存在正确，作用域是否可见；
- 类型派生：在分析树种各节点的字段类型等，如表链接后的字段类型。
- 聚集绑定：根据语法判定聚集的实际操作在宿主查询中。
- 分组绑定：验证group by 语法是否正确（select 后面的非聚集列必须是group by后面的）。
３.优化
查询优化是处理查询中最复杂部分，这部分由系统自动完成，如果说前面的环节告诉我们“做什么”，那么优化器就是描述“如何做”，查询优化器希望尽可能选择高效的执行计划。这部分将在本系列最后做一个专题。详细的阐述这里现提出流程（简化－－探索－－实现）。
总结：
本篇系统的介绍了编译查询的流程，以及产生缓存、复用缓存、重新编译等具体内容。对于优化我们的T-SQL语句来说有不少值得注意的地方，执行计划缓存的命中越多相应的我们的查询消耗也就越低，但是这种情况也不是绝对的。最后附加一个用于重新编译的工具和命令的超链接，里面有不少便于查询分析执行计划是否高效甚至存在问题功能和方法，http://www.cnblogs.com/wenBlog/p/4966991.html。