# EXPLAIN ## Name EXPLAIN?--?顯示一個語句的執行規劃 ## Synopsis ``` EXPLAIN [ ( _option_ [, ...] ) ] _statement_ EXPLAIN [ ANALYZE ] [ VERBOSE ] _statement_ 這里的 `_option_`可以是下列之一: ANALYZE [ _boolean_ ] VERBOSE [ _boolean_ ] COSTS [ _boolean_ ] BUFFERS [ _boolean_ ] TIMING [ _boolean_ ] FORMAT { TEXT | XML | JSON | YAML } ``` ## 描述 這條命令顯示PostgreSQL規劃器為所提供的語句生成的執行規劃。 執行規劃顯示語句引用的表是如何被掃描的(簡單的順序掃描，還是索掃描)，并且如果引用了多個表， 采用了什么樣的連接算法從每個輸入的表中取出所需要的記錄。 顯示出來的最關鍵的部分是預計的語句執行開銷，這就是規劃器對運行該語句所需時間的估計 (以任意的開銷單位計量，但是通常意味著磁盤頁面存取)。實際上顯示了兩個數字： 返回第一行記錄前的啟動開銷，和返回所有記錄的總開銷。對于大多數查詢而言，關心的是總開銷， 但是，在某些環境下，比如一個`EXISTS`子查詢里， 規劃器將選擇最小啟動開銷而不是最小總開銷(因為執行器在獲取一條記錄后總是要停下來)。 同樣，如果你用一條`LIMIT`子句限制返回的記錄數， 規劃器會在最終的開銷上做一個合理的插值以計算哪個規劃開銷最省。 `ANALYZE`選項導致查詢被實際執行，而不僅僅是規劃。顯示中加入了實際的運行時間統計， 包括在每個規劃節點內部花掉的總時間(以毫秒計)和它實際返回的行數。 這些數據對搜索該規劃器的預期是否和現實相近很有幫助。 > **Important:** 要記住的是查詢實際上在使用`ANALYZE`選項的時候是執行的。 盡管`EXPLAIN`會拋棄任何`SELECT`返回的輸出， 但是其它查詢的副作用還是一樣會發生的。如果你在`INSERT`, `UPDATE`, `DELETE`, `CREATE TABLE AS`, `EXECUTE` 語句里使用`EXPLAIN ANALYZE`而且還不想讓查詢影響數據，可以用下面的方法： > > ``` > BEGIN; > EXPLAIN ANALYZE ...; > ROLLBACK; > ``` 只能聲明`ANALYZE`和`VERBOSE`選項，并且只能以那種順序， 不能將選項列表放在圓括號中。PostgreSQL 9.0之前， 只支持不用圓括號的語法。人們希望只在圓括號語法中支持所有新的選項。 ## 參數 `ANALYZE` 執行命令并顯示實際運行時間和其他統計。這個參數缺省為`FALSE`。 `VERBOSE` 顯示關于規劃的額外的信息。特別的包括規劃樹上的每個節點的輸出字段列表， 模式修飾表和函數名，表達式中的標簽變量總是和他們的范圍表別名在一起， 并且總是打印統計數據中顯示的每個觸發器的名字。這個參數缺省為`FALSE`。 `COSTS` 包括每個規劃節點的估計啟動成本和總成本的信息，也包括估計行數和估計的每行的寬度。 這個參數缺省為`TRUE`。 `BUFFERS` 包含緩沖區使用的信息。特別的，包括共享塊命中、讀、臟和寫的次數，本地塊命中、讀、臟和寫的次數， 臨時塊讀和寫的次數。_命中_意味著避免了讀，因為塊在需要時已經在緩存中發現了。 共享塊包含普通表和索引的數據；本地塊包含臨時表和索引的數據；而臨時塊包含用于排序、哈希、 物化規劃節點和相似情況的短期工作數據。_臟_塊的數量表示這個查詢改變的先前未更改的塊的數量； _寫_塊的數量表示在查詢處理的時候被這個后端驅逐出緩存的先前臟了的塊的數量。 高級節點顯示的塊的數量包含所有它的子節點使用的塊的數量。在文本格式中，只打印非零值。 這個參數可能只在`ANALYZE`也啟用的時候使用。它的缺省為`FALSE`。 `TIMING` 在輸出中包含實際啟動時間和每個節點花費的時間。重復讀系統塊的總開銷會在某些系統上顯著的減緩查詢的速度， 所以當需要只有實際行被計算，并且沒有準確時間時，設置這個參數為`FALSE`會很有用。 即使是用這個選項關閉了節點級別的時間，也測量整個語句的運行時間。 這個參數可能只在`ANALYZE`也啟用的時候使用。它缺省為`TRUE`。 `FORMAT` 聲明輸出格式，可以為TEXT, XML, JSON 或 YAML。非文本的輸出包含文本輸出格式相同的信息， 但是更容易被程序解析。這個參數缺省為`TEXT`。 `_boolean_` 聲明選中的選項打開或者關閉。可以用`TRUE`, `ON` 或 `1` 啟用這個選項，用`FALSE`, `OFF` 或 `0` 禁用這個選項。在假設為`TRUE`的情況下， `_boolean_`值也可以忽略， `_statement_` 你想要查看執行規劃的任何`SELECT`, `INSERT`, `UPDATE`, `DELETE`, `VALUES`, `EXECUTE`, `DECLARE`, 或 `CREATE TABLE AS`語句之一。 ## 輸出 命令的結果是從`_statement_`選擇的規劃的文字描述， 可選的有執行統計數據的注釋。[Section 14.1](#calibre_link-1184)描述提供的信息。 ## 注意 為了讓PostgreSQL查詢規劃器在優化查詢的時候做出合理的判斷， [`pg_statistic`](#calibre_link-769) 數據應該為所有用于查詢的表更新。通常[autovacuum daemon](#calibre_link-77) 會自動注意這些。但是如果一個表最近在內容上有大量的更改，你可能需要手動[ANALYZE](#calibre_link-589) 而不是等待autovacuum趕上變化。 為了測量運行時在執行規劃中每個節點的開銷，`EXPLAIN ANALYZE` 的當前應用增加查詢執行開銷的性能分析。結果，在一個查詢上運行`EXPLAIN ANALYZE` 有時會比普通查詢明顯的花費更多的時間。超支的數量依賴于查詢的本質和使用的平臺。 最壞的情況發生在他們本身的規劃節點時每個執行需要非常少的時間， 并且在操作系統相當慢的機器上需要獲得時刻。 ## 例子 顯示一個對只有一個`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=39.53..39.53 rows=1 width=8) (actual time=0.661..0.672 rows=7 loops=1) -> Index Scan using test_pkey on test (cost=0.00..32.97 rows=1311 width=8) (actual time=0.050..0.395 rows=99 loops=1) Index Cond: ((id > $1) AND (id < $2)) Total runtime: 0.851 ms (4 rows) ``` 注意這里顯示的數字，依賴于所包含的表的實際內容。還請注意該數字甚至還有選擇的查詢策略都有可能在各個 PostgreSQL版本之間不同，因為規劃器在不斷改進。另外，`ANALYZE` 命令使用隨機的采樣來估計數據統計；因此，一次新的`ANALYZE` 運行之后開銷估計可能會變化，即使數據的實際分布沒有改變也這樣。 ## 兼容性 在 SQL 標準中沒有`EXPLAIN`語句。 ## 又見 [ANALYZE](#calibre_link-589)