SQL Server 针对用户提交的DML语句，通过一系列的优化后，产生出一个能被SQL Server识别并高效“响应”的方案，用Ctrl+M（实际执行计划）在用Ctrl+L（预估执行计划）
提交一个DML语句（CRUD）会引起一系列的活动。
1.发生在关系引擎中的活动
2.发生在存储引擎中的活动
在关系引擎中，查询被解析后传给查询优化器；在查询优化器中，查询被分析计算后生成执行计划，然后发给存储引擎，存储引擎按照计划查找或修改数据，之后返回给客户端
需要注意的是优化器产生的预估执行计划，而在存储引擎中产生的才是实际执行计划。这个计划可能与预估执行计划有出入，一下原因会导致二者有出入。
1.由于超过了并行执行的阈值，导致原有计划更改，使用了并行执行，
2.统计信息变更、过时、这时候也会更改预估执行计划
3.由于某些情况产生了重编译
二：预估与实际执行计划
1.执行计划有两类：一类是预估执行计划，由优化器产生，标识执行的逻辑步骤；另一类是实际执行计划，在实际执行计划中产生，标识实际执行的情况。
大部分情况下实际执行计划和预估执行计划是相同的，预估执行计划是存放在计划缓存中的，可以通过访问这些缓存中的计划得出统计数据。特别是对于一些大查询来说，获取实际执行计划往往不现实。实际执行计划可用于获取实际行数、实际统计信息。
2.执行计划重用
通过重用已经存在的计划缓存中的执行计划。可以大大降低服务器的开销。
在提交查询后，在Algebrizer阶段会创建一个hash数据用于唯一标识这个查询，并且会标识查询的语句，优化器会对比这个hash和缓存中hash，如果查询已经存在，它就会跳过优化并重用缓存中的执行计划。
为了重用执行计划，在编码时，尽可能编写一些SQL Server 重用的代码，参数化查询就是其中的一种，存储过程也是一个不错的选择，如果用硬编码的方式编写语句，即使少量的修改都会引起缓存丢失，因为脚本已经不同，SQL Server 无法找到缓存的hash值，会引起不必要的优化开销。
SQLServer 不会永久保存计划的缓存，并且存在缓存中的计划也不会永久不变，每个计划都会有一个age值，当Algebrizer触发时，会扫描这个age值，并且每次降低这个值。
在满足下面全部的条件时，预估执行计划会被移除出内存。
1.操作系统需要更多的内存
2.Age值已经降低到0
3.执行计划没有被当前的连接使用
导致执行计划重新编译，得避免下面的情景。
1.查询所引用的表结构或者架构更改
2.查询所用的索引更改
3.查询用到的索引被删除
4.显示调用sp_recompile
5.查询引用的表上，由于在键值上有大量的Insert/Delete操作，引起了统计信息的更改
6.单一查询中混合了DDL和DML操作，称为延迟编译
7.在查询中修改了SET选项
8.查询所用到的临时表的架构、结构修改
9.查询过程中游标选项更改
三：清除缓存中的执行计划
DBCC FREEPROCCACHE
四：执行计划格式