描述

這個指令會顯示 PostgreSQL 規劃器為提供的陳述式產生的執行計畫。執行計畫會顯示陳述式引用的資料表將如何掃描 — 透過簡單的循序掃描、索引掃描等等 — 以及如果引用了多個資料表，將使用哪些聯結演算法來將每個輸入資料表中的必要列組合在一起。

顯示中最關鍵的部分是預估的陳述式執行成本，這是規劃器對執行陳述式所需時間的猜測（以任意的成本單位衡量，但通常表示磁碟頁面提取）。實際上顯示了兩個數字：傳回第一列之前的啟動成本，以及傳回所有列的總成本。對於大多數查詢，總成本才是重要的，但在諸如 EXISTS 中的子查詢等情況下，規劃器會選擇最小的啟動成本而不是最小的總成本（因為執行器在取得一列後會停止）。此外，如果您使用 LIMIT 子句限制要傳回的列數，規劃器會在端點成本之間進行適當的插值，以估計哪個計畫才是真正最便宜的。

ANALYZE 選項會導致實際執行陳述式，而不僅僅是規劃。然後，實際的執行時間統計資料會新增到顯示中，包括每個計畫節點中花費的總經過時間（以毫秒為單位）以及它實際傳回的總列數。這對於查看規劃器的估計是否接近實際情況很有用。

BEGIN;
EXPLAIN ANALYZE ...;
ROLLBACK;

參數

Outputs

命令的結果是為 statement 選擇的計畫的文字描述，可以選擇使用執行統計資料進行註解。Section 14.1 描述了提供的資訊。

Notes

為了讓 PostgreSQL 查詢規劃器在最佳化查詢時做出合理且明智的決策，用於查詢的所有資料表的 pg_statistic 資料應該是最新的。通常，自動清理精靈會自動處理此事。但是，如果資料表最近的內容發生了重大變更，則可能需要手動執行 ANALYZE，而不是等待自動清理趕上變更。

為了測量執行計畫中每個節點的執行時間成本，目前 EXPLAIN ANALYZE 的實作會將分析額外負荷新增到查詢執行中。因此，在查詢上執行 EXPLAIN ANALYZE 有時可能比正常執行查詢花費的時間長得多。額外負荷的大小取決於查詢的性質以及使用的平台。最糟糕的情況是計畫節點本身每次執行所需的時間非常少，並且機器獲取當天時間的作業系統呼叫相對較慢。

Examples

顯示具有單一 integer 欄位和 10000 列的資料表上的簡單查詢的計畫

EXPLAIN SELECT * FROM foo;

                       QUERY PLAN
---------------------------------------------------------
 Seq Scan on foo  (cost=0.00..155.00 rows=10000 width=4)
(1 row)

這是相同的查詢，採用 JSON 輸出格式

EXPLAIN (FORMAT JSON) SELECT * FROM foo;
           QUERY PLAN
--------------------------------
 [                             +
   {                           +
     "Plan": {                 +
       "Node Type": "Seq Scan",+
       "Relation Name": "foo", +
       "Alias": "foo",         +
       "Startup Cost": 0.00,   +
       "Total Cost": 155.00,   +
       "Plan Rows": 10000,     +
       "Plan Width": 4         +
     }                         +
   }                           +
 ]
(1 row)

如果存在索引，並且我們使用具有可索引 WHERE 條件的查詢，則 EXPLAIN 可能會顯示不同的計畫

EXPLAIN SELECT * FROM foo WHERE i = 4;

                         QUERY PLAN
--------------------------------------------------------------
 Index Scan using fi on foo  (cost=0.00..5.98 rows=1 width=4)
   Index Cond: (i = 4)
(2 rows)

這是相同的查詢，但採用 YAML 格式

EXPLAIN (FORMAT YAML) SELECT * FROM foo WHERE i='4';
          QUERY PLAN
-------------------------------
 - Plan:                      +
     Node Type: "Index Scan"  +
     Scan Direction: "Forward"+
     Index Name: "fi"         +
     Relation Name: "foo"     +
     Alias: "foo"             +
     Startup Cost: 0.00       +
     Total Cost: 5.98         +
     Plan Rows: 1             +
     Plan Width: 4            +
     Index Cond: "(i = 4)"
(1 row)

XML 格式留給讀者作為練習。

這是相同的計畫，但隱藏了成本估算

EXPLAIN (COSTS FALSE) SELECT * FROM foo WHERE i = 4;

        QUERY PLAN
----------------------------
 Index Scan using fi on foo
   Index Cond: (i = 4)
(2 rows)

這是一個查詢的查詢計畫範例，該查詢使用聚合函式

EXPLAIN SELECT sum(i) FROM foo WHERE i < 10;

                             QUERY PLAN
-------------------------------------------------------------------​--
 Aggregate  (cost=23.93..23.93 rows=1 width=4)
   ->  Index Scan using fi on foo  (cost=0.00..23.92 rows=6 width=4)
         Index Cond: (i < 10)
(3 rows)

這是一個使用 EXPLAIN EXECUTE 顯示預備查詢的執行計畫的範例

PREPARE query(int, int) AS SELECT sum(bar) FROM test
    WHERE id > $1 AND id < $2
    GROUP BY foo;

EXPLAIN ANALYZE EXECUTE query(100, 200);

                                                       QUERY PLAN
-------------------------------------------------------------------​------------------------------------------------------
 HashAggregate  (cost=10.77..10.87 rows=10 width=12) (actual time=0.043..0.044 rows=10 loops=1)
   Group Key: foo
   Batches: 1  Memory Usage: 24kB
   ->  Index Scan using test_pkey on test  (cost=0.29..10.27 rows=99 width=8) (actual time=0.009..0.025 rows=99 loops=1)
         Index Cond: ((id > 100) AND (id < 200))
 Planning Time: 0.244 ms
 Execution Time: 0.073 ms
(7 rows)

當然，此處顯示的特定數字取決於所涉及資料表的實際內容。另請注意，由於規劃器改進，這些數字，甚至選定的查詢策略，可能會在 PostgreSQL 版本之間有所不同。此外，ANALYZE 命令使用隨機取樣來估算資料統計資料；因此，即使資料表中資料的實際分佈沒有改變，在重新執行 ANALYZE 後，成本估算仍有可能改變。

請注意，先前的範例顯示了 EXECUTE 中給定的特定參數值的 「自訂」計畫。我們可能也希望查看參數化查詢的通用計畫，可以使用 GENERIC_PLAN 來完成

EXPLAIN (GENERIC_PLAN)
  SELECT sum(bar) FROM test
    WHERE id > $1 AND id < $2
    GROUP BY foo;

                                  QUERY PLAN
-------------------------------------------------------------------​------------
 HashAggregate  (cost=26.79..26.89 rows=10 width=12)
   Group Key: foo
   ->  Index Scan using test_pkey on test  (cost=0.29..24.29 rows=500 width=8)
         Index Cond: ((id > $1) AND (id < $2))
(4 rows)

在本例中，剖析器正確地推斷出 $1 和 $2 應與 id 具有相同的資料類型，因此，來自 PREPARE 的參數類型資訊的缺乏並不是問題。在其他情況下，可能需要明確指定參數符號的類型，這可以透過轉換它們來完成，例如

EXPLAIN (GENERIC_PLAN)
  SELECT sum(bar) FROM test
    WHERE id > $1::integer AND id < $2::integer
    GROUP BY foo;

相容性

SQL 標準中沒有定義 EXPLAIN 語句。

在 PostgreSQL 9.0 版之前使用以下語法，並且仍然支援

EXPLAIN [ ANALYZE ] [ VERBOSE ] statement

請注意，在此語法中，選項必須完全按照顯示的順序指定。

參見