# 46.5\. 规划器/优化器 _规划器/优化器_的任务是创建一个优化执行规划。 一个特定的 SQL 查询(因此也就是一个查询树)实际上可以以多种不同的方式执行， 每种都生成相同的结果集。如果可能，查询优化器将检查每个可能的执行规划， 最终选择认为运行最快的执行计划。 > **Note:** 有些情况下，检查一个查询所有可能的执行方式会花去很多时间和内存空间。 特别是在正在执行的查询涉及大量连接操作的时候。 为了在合理的时间里判断一个合理的(而不是优化的)查询计划。PostgreSQL 当连接的数量超过一个阈值(参阅 [geqo_threshold](#calibre_link-611))时使用 _基因查询优化器_(参阅[Chapter 53](#calibre_link-529))。 规划器的搜索过程实际上是与叫做_paths_的数据结构一起结合运转的， 这个数据结构是一个很简单的规划的精简版本，它只包括规划器用来决策所必须的信息。 在找到最经济的路径之后，就制作一个完整的_规划树_传递给执行器。 它有足够的详细信息，代表着需要执行的计划，执行器可以读懂并运行之。在本章剩余部分， 将忽略路径和规划之间的区别。 ## 46.5.1\. 生成可能的规划 规划器/优化器通过为扫描查询里出现的每个关系(表)生成规划。 可能的规划是由每个关系上有哪些可用的索引决定的。对一个关系总是可以进行一次顺序查找， 所以总是会创建只使用顺序查找的规划。假设一个关系上定义着一个索引(例如 B-tree 索引)， 并且一条查询包含约束`relation.attribute OPR constant`。 如果`relation.attribute`碰巧匹配 B-tree 索引的关键字并且`OPR` 又是列出在索引的_操作符类_中的操作符中的一个， 那么将会创建另一个使用 B-tree 索引扫描该关系的规划。如果还有别的索引， 而且查询里面的约束又和那个索引的关键字匹配，则还会生成更多的规划。也会为索引生成索引扫描规划， 这个规划有一种可以匹配查询的`ORDER BY`子句（如果有）的顺序， 或者有一种可能对融合加入（见下面）有用的顺序。 如果查询需要加入两个或者更多的关系，在所有的对单一关系的扫描可行的规划被发现后， 连接各个关系的规划就要被考虑了。有三种可能的连接策略： * _嵌套循环连接_：对左边的关系里面找到的每条行都对右边关系进行一次扫描。 这个策略容易实现，但是可能会很耗费时间。（但是，如果右边的关系可以用索引扫描， 那么这个可能就是个好策略。可以用来自左边关系的当前行的数值为键字进行对右边关系的索引扫描。） * _融合连接_：在连接开始之前，每个关系都对连接字段进行排序。 然后对两个关系并发扫描，匹配的行就组合起来形成连接行。这种联合更有吸引力， 因为每个关系都只用扫描一次。要求的排序步骤可以通过明确的排序步骤， 或者是使用连接键字上的索引按照恰当的顺序扫描关系。 * _Hash 连接_：首先扫描右边的关系， 并用连接的字段作为散列键字加载进入一个 Hash 表，然后扫描左边的关系， 并将找到的每行用作散列键字来以定位表里匹配的行。 如果查询里的关系多于两个，最后的结果必须通过一个连接步骤树建立， 每个步骤有两个输入。规划器检查不同的连接顺序可能，找出开销最小的。 如果查询使用少于[geqo_threshold](#calibre_link-611)的关系， 一个近乎详尽的查询用来进行查找最好的连接顺序。规划器优先的考虑介于任何两个关系间的连接子句， 在`WHERE`条件中存在一个匹配的连接子句（例如，存在像 `where rel1.attr1=rel2.attr2`这样的约束）。 没有连接子句的连接对只有在没有别的选择的时候才考虑，也就是说， 一个关系没有和任何其它关系的连接子句可用。所有可能的规划都是为每个被规划器考虑的链接对生成的， 并且那个（预计是）最经济的被选择。 当`geqo_threshold`溢出时，连接序列被认为是由启发式方法决定的， 描述在[Chapter 53](#calibre_link-529)。否则，流程是相同的。 完成的查询树由对基础关系的顺序或者索引扫描组成，并根据需要加上嵌套循环、融合、以及 Hash 连接节点， 加上任何需要的辅助步骤，比如排序节点或者聚集函数计算节点等。 大多数这些规划节点类型都有额外的做_选择_ (抛弃那些不符合指定布尔条件的行)和_投影_ (基于给出的字段数值计算一个派生出的字段集， 也就是在需要时计算标量表达式)。规划器的一个责任是从`WHERE` 子句中附加选择条件以及为规划树最合适的节点计算所需要的输出表达式。