# 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` 子句中附加選擇條件以及為規劃樹最合適的節點計算所需要的輸出表達式。