5 . 2 查 询 优 化 器

5 . 2 查 询 优 化 器
从本质上来说，优化器执行的就是一个把逻辑查询操作映射为物理操作，并把产生的
执行计划传递给执行引擎运行并返回结果给用户的过程。优化器会通过一定数量的算法计
算，选择最低开销的操作，尽可能确保査询被高效执行。因此，优化过程的最终产物是一
个预估执行计划，其中包含了数个物理操作符的树，并蕴含了一定的算法。执行引擎通过
这个树，操作数据库的数据，最终返回结果。
5 .2 .1 产 生 执 行 计 划
正如前面所说，优化器的目标是寻找及产生高效的执行计划，事实上，即使是相对简
单的查询，也可能产生大量不同的执行计划。优化器会把能够产生相同结果的这些计划放
在一个叫作“查询空间（search space)” 的地方，然后进行基于开销的预估。因为执行计划 的数量可能很庞大，优化器必须平衡各种执行计划，甚至平衡产生执行计划的数量。SQL
Server没有必要为了一个只需运行几秒或者一分钟的查询，花费超过5 分钟的时间去编译、 优化。
为了处理查询空间，优化器会使用转换规则和试探法，在优化器内部使用转换规则，
产生一定数量的执行计划，然后使用试探法，限制候选计划的数量，使得优化时间能够合
理化。在优化过程中，候选计划会存放在内存中，这部分内存叫做Memo (由于没有官方说 明，所以这里暂且称为备忘录）。转换规则、试探法以及备忘录会在后续作介绍。
1 .评估每个计划的开销
穷举每个候选计划是优化过程的一部分，因此优化器需要预估每个计划的开销，并选
择最小的一个作为最终预估执行计划。为了实现这种预估，优化器会针对每个物理操作符
使用开销公式进行开销计算。这些开销公式由使用的资源，比如I/O、CPU和内存组成。
为了协助预估开销，SQL Server会使用及维护优化器的统计信息，这些统计信息来自于表 中的一行或多行数据的分布状态。在对每个物理操作符预估之后，汇总成整个计划的总体
预估。
2 .查询执行及计划缓存
一旦査询被优化，最终计划就会用于执行引擎并操作数据。产生的这个计划会存放在
内存中一个叫计划缓存（plan cache,在以前版本中叫procedure cache)的地方，以便能被

相同的査询重用。如果一个可用的计划已经存放在计划缓存中，优化器会跳过优化，直接
执行，减少优化时间、CPU资源等开销。
但是重用计划并不总是好事，因为现实数据及应用情景一直在变动，比如，同一个查询
的不同参数可能会因为对应数据的分布差异很大从而导致执行计划不合适，如果依旧重用计
划，查询性能就会大大降低，这种情况叫做参数嗅探。参数嗅探的内容将在本章后面介绍。
除了参数嗅探，一些元数据的变更，比如索引、约束、足够的数据量变化等，都会导
致计划缓存的适用性降低。另外，执行计划会在SQL Server处于内存压力或者特定语句命 令执行时被从计划缓存中移除。
3 . 提示
绝大部分时候，我们不应该干预优化器的工作，因为它比我们更清楚自身的情况，但
是在某些情况下，由于一些不可避免的因素，优化器也会做出非预期的选择，这时候，提
示 （hint)就有用武之地了。在深人了解了优化器及执行计划和相关因素之后，可以借助提 示，对査询性能进行短期的干预。记住，不要进行长期干预。这部分知识后续也会进一步
介绍。