14.1. 使用EXPLAIN · PostgreSQL 中文文檔 9.3

# 14.1\. 使用`EXPLAIN` PostgreSQL對每個查詢產生一個_查詢規劃_。為匹配查詢結構和數據屬性選擇正確的規劃對性能絕對有關鍵性的影響。因此系統包含了一個復雜的規劃器用于尋找最優的規劃。你可以使用[EXPLAIN](#calibre_link-575)命令察看規劃器為每個查詢生成的查詢規劃是什么。閱讀查詢規劃是一門值得專門寫一厚本教程的學問，但是這部分試圖掩蓋這些基本信息。本節的例子是從數據庫執行`VACUUM ANALYZE`之后的回歸測試中提取的，使用9.3開發源。如果你嘗試自己的例子，你應該可以得到類似結果，但你的估計成本及行數可能會略有不同，因為 `ANALYZE`的統計數據是隨機樣本，而不是確切的，并且因為成本本身有點依賴于平臺。該示例使用`EXPLAIN`的缺省"文本"輸出格式，它結構緊湊，便于人們閱讀。如果你想為進一步分析提供`EXPLAIN`輸出給程序，你應該使用它的機器可讀的輸出格式之一(XML, JSON, or YAML)來代替。 ## 14.1.1\. `EXPLAIN`基礎查詢規劃的結構是一個_規劃節點_的樹。最底層的節點是表掃描節點：它們從表中返回原始數據行。不同的表訪問模式有不同的掃描節點類型：順序掃描、索引掃描、位圖索引掃描。也有非表行來源，如`VALUES`子句和`FROM`中的設置返回函數，其中有他們自己的掃描節點類型。如果查詢需要連接、聚集、排序、或者對原始行的其它操作，那么就會在掃描節點之上有其它額外的節點。并且，做這些操作通常都有多種方法，因此在這些位置也有可能出現不同的節點類型。`EXPLAIN`給規劃樹中每個節點都輸出一行，顯示基本的節點類型和規劃器為執行這個規劃節點預計的開銷值。其他行可能會出現，從節點的匯總行縮進，以顯示節點的附加屬性。第一行(最上層的匯總行節點)是對該規劃的總執行開銷的預計；這個數值就是規劃器試圖最小化的數值這里是一個簡單的例子，只是用來顯示輸出會有些什么內容： ``` EXPLAIN SELECT * FROM tenk1; QUERY PLAN ------------------------------------------------------------- Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244) ``` 由于此查詢沒有`WHERE`子句，它必須掃描所有表的行，所以規劃器已經選擇使用一個簡單的順序掃描計劃。括號中引用的數值是（從左到右）: * 預計的啟動開銷。在輸出掃描開始之前消耗的時間，也就是在一個排序節點里執行排序的時間。 * 預計總開銷。這是假設所規定的，計劃節點運行完成，即所有可用行被檢索。在實踐中一個節點的父節點可能會很快停止讀取所有可用的行（參見`LIMIT`下面的例子）。 * 預計這個規劃節點輸出的行數。同樣，只執行到完成為止。 * 預計這個規劃節點的行平均寬度(以字節計算)。開銷是用規劃器根據成本參數(參見節[Section 18.7.2](#calibre_link-1200))捏造的單位來衡量的，習慣上以磁盤頁面抓取為單位。也就是[seq_page_cost](#calibre_link-1201)將被按照習慣設為`1.0`(一次順序的磁盤頁面抓取)，其它開銷參數將參照它來設置。本節的例子都假定這些參數使用默認值。有一點很重要：一個上層節點的開銷包括它的所有子節點的開銷。還有一點也很重要：這個開銷只反映規劃器關心的東西，尤其是沒有把結果行傳遞給客戶端的時間考慮進去，這個時間可能在實際的總時間里占據相當重要的分量，但是被規劃器忽略了，因為它無法通過修改規劃來改變：我們相信，每個正確的規劃都將輸出同樣的記錄集。 `行`值有一些小技巧，因為它不是規劃節點處理/掃描過的行數，而是節點發射數目。通常會少于掃描數，正如應用于此節點上的任意`WHERE`子句條件的過濾結果。通常而言，頂層的行預計會接近于查詢實際返回、更新、刪除的行數。回到我們的例子： ``` EXPLAIN SELECT * FROM tenk1; QUERY PLAN ------------------------------------------------------------- Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244) ``` 這些數字的獲得非常直截了當。如果你這樣做： ``` SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1'; ``` 你會發現`tenk1`有 358 磁盤頁面和 10000 行。估計成本作為（磁盤頁面讀取*[seq_page_cost](#calibre_link-1201)）+（行掃描*[cpu_tuple_cost](#calibre_link-1178)）被計算。默認情況下， `seq_page_cost`是1.0，`cpu_tuple_cost`是0.01, 因此估計成本為(358 * 1.0) + (10000 * 0.01) = 458。現在讓我們修改查詢并增加一個`WHERE`條件： ``` EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 7000; QUERY PLAN ------------------------------------------------------------ Seq Scan on tenk1 (cost=0.00..483.00 rows=7001 width=244) Filter: (unique1 < 7000) ``` 請注意`EXPLAIN`輸出顯示`WHERE`子句當作一個"filter"條件附屬于順序掃描計劃節點。這意味著規劃節點為它掃描的每一行檢查該條件，并且只輸出符合條件的行。預計的輸出行數降低了，因為有`WHERE`子句。不過，掃描仍將必須訪問所有 10000 行，因此開銷沒有降低；實際上它還增加了一些（確切的說，通過10000 * [cpu_operator_cost](#calibre_link-735)）以反映檢查`WHERE`條件的額外CPU時間。這條查詢實際選擇的行數是7000 ，但是預計的`行數`只是個大概。如果你試圖重復這個試驗，那么你很可能得到不同的預計。還有，這個預計會在每次`ANALYZE`命令之后改變，因為`ANALYZE`生成的統計是從該表中隨機抽取的樣本計算的。把查詢限制條件改得更嚴格一些： ``` EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100; QUERY PLAN ------------------------------------------------------------------------------ Bitmap Heap Scan on tenk1 (cost=5.07..229.20 rows=101 width=244) Recheck Cond: (unique1 < 100) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) Index Cond: (unique1 < 100) ``` 這里，規劃器決定使用兩步的規劃：最底層的規劃節點訪問一個索引，找出匹配索引條件的行的位置，然后上層規劃節點真實地從表中抓取出那些行。獨立地抓取數據行比順序地讀取它們的開銷高很多，但是因為并非所有表的頁面都被訪問了，這么做實際上仍然比一次順序掃描開銷要少。使用兩層規劃的原因是因為上層規劃節點把索引標識出來的行位置在讀取它們之前按照物理位置排序，這樣可以最小化獨立抓取的開銷。節點名稱里面提到的"bitmap"是進行排序的機制。現在讓我們添加另外一個條件到`WHERE`子句： ``` EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND stringu1 = 'xxx'; QUERY PLAN ------------------------------------------------------------------------------ Bitmap Heap Scan on tenk1 (cost=5.04..229.43 rows=1 width=244) Recheck Cond: (unique1 < 100) Filter: (stringu1 = 'xxx'::name) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) Index Cond: (unique1 < 100) ``` 新增的條件`stringu1 = 'xxx'`減少了預計的輸出行，但是沒有減少開銷，因為我們仍然需要訪問相同的行。請注意，`stringu1`子句不能當做一個索引條件使用(因為這個索引只是在`unique1`列上有)。它被當做一個從索引中檢索出的行的過濾器來使用。因此開銷實際上略微增加了一些以反映這個額外的檢查。在某些情況下規劃區更加喜歡"simple"索引掃描規劃： ``` EXPLAIN SELECT * FROM tenk1 WHERE unique1 = 42; QUERY PLAN ----------------------------------------------------------------------------- Index Scan using tenk1_unique1 on tenk1 (cost=0.29..8.30 rows=1 width=244) Index Cond: (unique1 = 42) ``` 在這種規劃類型中，表的數據行是以索引順序抓取的，這樣就令讀取它們的開銷更大，但是這里的行少得可憐，因此對行位置的額外排序并不值得。最常見的就是看到這種規劃類型只抓取一行，以及那些要求`ORDER BY`條件匹配索引順序的查詢。因為那時候沒有多余的排序步驟是必要的以滿足`ORDER BY`。如果在`WHERE`里面使用的好幾個字段上都有索引，那么規劃器可能會使用索引的AND或OR的組合： ``` EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000; QUERY PLAN ------------------------------------------------------------------------------------- Bitmap Heap Scan on tenk1 (cost=25.08..60.21 rows=10 width=244) Recheck Cond: ((unique1 < 100) AND (unique2 > 9000)) -> BitmapAnd (cost=25.08..25.08 rows=10 width=0) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) Index Cond: (unique1 < 100) -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0) Index Cond: (unique2 > 9000) ``` 但是這么做要求訪問兩個索引，因此與只使用一個索引，而把另外一個條件只當作過濾器相比，這個方法未必是更優。如果你改變涉及的范圍，你會看到規劃器相應地發生變化。下面是一個例子，顯示`LIMIT`的影響： ``` EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000 LIMIT 2; QUERY PLAN ------------------------------------------------------------------------------------- Limit (cost=0.29..14.48 rows=2 width=244) -> Index Scan using tenk1_unique2 on tenk1 (cost=0.29..71.27 rows=10 width=244) Index Cond: (unique2 > 9000) Filter: (unique1 < 100) ``` 這是上面相同的查詢，但我們增加了`LIMIT`，以致于不是所有的行需要被檢索，并且規劃關于該怎么做改變了主意，請注意，索引掃描節點的總成本和行數被顯示，好像它是運行完畢的。然而，限制節點預計在提取這些行的僅僅五分之一后停止，所以其總成本只有五分之一之多，這就是實際的預算費用查詢。該計劃優于增加一個限制節點到先前的計劃，因為該限制無法避免支付位圖掃描的啟動成本，所以總成本將超過使用這種方法的25個單位的東西。讓我們試著使用我們上面討論的字段連接兩個表： ``` EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 10 AND t1.unique2 = t2.unique2; QUERY PLAN -------------------------------------------------------------------------------------- Nested Loop (cost=4.65..118.62 rows=10 width=488) -> Bitmap Heap Scan on tenk1 t1 (cost=4.36..39.47 rows=10 width=244) Recheck Cond: (unique1 < 10) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..4.36 rows=10 width=0) Index Cond: (unique1 < 10) -> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244) Index Cond: (unique2 = t1.unique2) ``` 在這個規劃中，我們有兩個表掃描的作為輸入或者子節點的嵌套循環連接節點，節點摘要行的縮進反映規劃樹結構。連接的第一個，或者"outer"，子節點就是類似于我們之前看到的位圖掃描。其成本和行數是一樣的，正如我們從`SELECT ... WHERE unique1 < 10`獲得。因為我們只能在那個節點上應用`WHERE` clause `unique1 < 10`。`t1.unique2 = t2.unique2` 子句還沒有任何關系。因此它不影響外層掃描的行計數。嵌套循環連接節點將運行它的第二部分，或者"inner"子節點一次從外部子節點獲得每一行。從目前的外層行獲得的值可以被插入到內掃描。這兒，從外層行中獲得的`t1.unique2`是可用的。這樣我們就得到一個計劃和成本，并且類似于我們上面看到的簡單的`SELECT ... WHERE t2.unique2 =` `_constant_`的情況。（估計費用實際上比上面看到的低一點，在`t2`上可重復的索引掃描期間，作為期望發生的高速緩存結果）。以外層掃描的開銷為基礎設置循環節點的開銷，加上每個外層行的一個重復(這里是10 * 7.87)，然后再加上連接處理需要的一點點CPU時間。在這個例子里，連接的輸出行數與兩個掃描的行數的乘積相同，但通常并不是這樣的，因為通常你會有提及兩個表的`WHERE`子句，因此它只能應用于連接(join)點，而不能影響兩個關系的輸入掃描。這里有一個例子： ``` EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 10 AND t2.unique2 < 10 AND t1.hundred < t2.hundred; QUERY PLAN --------------------------------------------------------------------------------------------- Nested Loop (cost=4.65..49.46 rows=33 width=488) Join Filter: (t1.hundred < t2.hundred) -> Bitmap Heap Scan on tenk1 t1 (cost=4.36..39.47 rows=10 width=244) Recheck Cond: (unique1 < 10) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..4.36 rows=10 width=0) Index Cond: (unique1 < 10) -> Materialize (cost=0.29..8.51 rows=10 width=244) -> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..8.46 rows=10 width=244) Index Cond: (unique2 < 10) ``` 條件`t1.hundred < t2.hundred`不能在`tenk2_unique2`索引中被測試，因此它被應用在連接節點。這減少了連接節點的預計輸出行數，但不改變任何一個輸入掃描。注意，這里的規劃器已經選擇"具體化"連接內部關系，通過放在規劃節點上面。這也就是說，`t2`索引掃描將執行一次，盡管嵌套循環連接節點需要讀取數據十次，來自外部關系的每一行。實現節點將數據保存在存儲器中，因為它被讀取，然后從存儲器每個后續過程中返回每一個數據。當與外部聯接時，你可能會看到帶有附屬"Join Filter"以及純"Filter"條件的連接計劃節點。連接過濾條件來自于外部連接的`ON`子句，因此這樣的行失敗了，連接過濾條件仍然可以作為非擴展行發出。但一個純過濾條件可以在外連接規則之后被應用因此這個行為無條件地刪除行。在內連接中這些過濾器類型之間沒有語義差異。如果我們改變查詢的選擇性，我們可能會得到一個非常不同的連接計劃: ``` EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; QUERY PLAN ------------------------------------------------------------------------------------------ Hash Join (cost=230.47..713.98 rows=101 width=488) Hash Cond: (t2.unique2 = t1.unique2) -> Seq Scan on tenk2 t2 (cost=0.00..445.00 rows=10000 width=244) -> Hash (cost=229.20..229.20 rows=101 width=244) -> Bitmap Heap Scan on tenk1 t1 (cost=5.07..229.20 rows=101 width=244) Recheck Cond: (unique1 < 100) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) Index Cond: (unique1 < 100) ``` 在這里，規劃器選擇使用一個哈希聯接，表中的行被輸入到內存中的哈希表中，在此之后，其他表被掃描并且哈希表進行探測以匹配每一行。再次注意如何縮進來反映規劃結構：在`tenk1`上的位圖掃描是輸入到哈希節點，它構造哈希表。這之后返回哈希連接節點，其內容是從它的外部子計劃中讀取每一行并且搜索每一個哈希表。另一種可能的連接類型是合并連接，在這里說明： ``` EXPLAIN SELECT * FROM tenk1 t1, onek t2 WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; QUERY PLAN ------------------------------------------------------------------------------------------ Merge Join (cost=198.11..268.19 rows=10 width=488) Merge Cond: (t1.unique2 = t2.unique2) -> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244) Filter: (unique1 < 100) -> Sort (cost=197.83..200.33 rows=1000 width=244) Sort Key: t2.unique2 -> Seq Scan on onek t2 (cost=0.00..148.00 rows=1000 width=244) ``` 合并連接要求其輸入的數據在連接鍵上進行排序。在這種規劃中`tenk1`數據是通過使用索引掃描訪問正確順序的行來進行排序。但順序掃描和排序是`onek`的首選，因為有該表上被訪問的更多行。（順序掃描和排序為排序行數而頻繁進行索引掃描，因為通過索引掃描需要不連續的磁盤訪問）找另外一個規劃的方法是通過設置每種規劃類型的允許/禁止開關(在[Section 18.7.1](#calibre_link-1202)里描述)，強制規劃器拋棄它認為優秀的(掃描)策略。這個工具目前比較原始，但很有用。又見[Section 14.3](#calibre_link-1189)。例如，如果我們不相信順序掃描和排序對于前面例子中處理表`onek`是最好的方式，我們可以嘗試 ``` SET enable_sort = off; EXPLAIN SELECT * FROM tenk1 t1, onek t2 WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2; QUERY PLAN ------------------------------------------------------------------------------------------ Merge Join (cost=0.56..292.65 rows=10 width=488) Merge Cond: (t1.unique2 = t2.unique2) -> Index Scan using tenk1_unique2 on tenk1 t1 (cost=0.29..656.28 rows=101 width=244) Filter: (unique1 < 100) -> Index Scan using onek_unique2 on onek t2 (cost=0.28..224.79 rows=1000 width=244) ``` 這表明規劃期認為通過索引掃描排序`onek`比順序掃描和排序更昂貴約12％。當然，接下來的問題是它是否是對的。我們可以使用`EXPLAIN ANALYZE`調查，正如下面所討論的： ## 14.1.2\. `EXPLAIN ANALYZE` 我們可以用`EXPLAIN`的`ANALYZE`檢查規劃器的估計值的準確性。這個命令實際上執行該查詢然后顯示每個規劃節點內實際運行時間的和以及單純`EXPLAIN`顯示的估計開銷。比如，我們可以像下面這樣獲取一個結果： ``` EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 10 AND t1.unique2 = t2.unique2; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------- Nested Loop (cost=4.65..118.62 rows=10 width=488) (actual time=0.128..0.377 rows=10 loops=1) -> Bitmap Heap Scan on tenk1 t1 (cost=4.36..39.47 rows=10 width=244) (actual time=0.057..0.121 rows=10 loops=1) Recheck Cond: (unique1 < 10) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..4.36 rows=10 width=0) (actual time=0.024..0.024 rows=10 loops=1) Index Cond: (unique1 < 10) -> Index Scan using tenk2_unique2 on tenk2 t2 (cost=0.29..7.91 rows=1 width=244) (actual time=0.021..0.022 rows=1 loops=10) Index Cond: (unique2 = t1.unique2) Total runtime: 0.501 ms ``` 請注意"actual time"數值是以真實時間的毫秒計的，而`cost`估計值是以任意磁盤抓取的單元計的；因此它們很可能不一致。我們要關心的事是兩組比值是否一致。通常最重要的事情是看是否估計行數相當接近于現實。在這個例子中，估計都是完全正確的，但是這是相當不尋常的做法。在一些查詢規劃里，一個子規劃節點很可能運行多次。比如，在上面的嵌套循環的規劃里，內層的索引掃描對每個外層行執行一次。在這種情況下，`loops`報告該節點執行的總數目，而顯示的實際時間和行數目是每次執行的平均值。這么做的原因是令這些數字與開銷預計顯示的數字具有可比性。要乘以`loops`值才能獲得在該節點花費的總時間。在上面的例子中，我們共需要0.220毫秒來執行`tenk2`的索引掃描。在某些情況下`EXPLAIN ANALYZE`顯示超出規劃節點執行時間和行數的額外執行統計數據。例如，排序和哈希節點提供額外的信息： ``` EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 100 AND t1.unique2 = t2.unique2 ORDER BY t1.fivethous; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------- Sort (cost=717.34..717.59 rows=101 width=488) (actual time=7.761..7.774 rows=100 loops=1) Sort Key: t1.fivethous Sort Method: quicksort Memory: 77kB -> Hash Join (cost=230.47..713.98 rows=101 width=488) (actual time=0.711..7.427 rows=100 loops=1) Hash Cond: (t2.unique2 = t1.unique2) -> Seq Scan on tenk2 t2 (cost=0.00..445.00 rows=10000 width=244) (actual time=0.007..2.583 rows=10000 loops=1) -> Hash (cost=229.20..229.20 rows=101 width=244) (actual time=0.659..0.659 rows=100 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 28kB -> Bitmap Heap Scan on tenk1 t1 (cost=5.07..229.20 rows=101 width=244) (actual time=0.080..0.526 rows=100 loops=1) Recheck Cond: (unique1 < 100) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.049..0.049 rows=100 loops=1) Index Cond: (unique1 < 100) Total runtime: 8.008 ms ``` 排序節點顯示使用的排序方法（特別是，排序是否在內存或磁盤上）以及所需的內存或磁盤空間量。哈希節點顯示哈希桶數量以及批處理用于哈希表的內存峰值數。（如果批處理數大于1，也將有參與磁盤空間使用情況，但不在這顯示。另一種類型的附加信息是通過過濾條件刪除行數： ``` EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE ten < 7; QUERY PLAN --------------------------------------------------------------------------------------------------------- Seq Scan on tenk1 (cost=0.00..483.00 rows=7000 width=244) (actual time=0.016..5.107 rows=7000 loops=1) Filter: (ten < 7) Rows Removed by Filter: 3000 Total runtime: 5.905 ms ``` 這些計數對于應用在連接節點的過濾條件特別有價值。 "刪除行"只出現在掃描行，或者連接節點的情況下的潛在連接對，通過過濾條件被拒絕。類似的情況，過濾條件產生"lossy"的索引掃描。例如，考慮多邊形這個搜索包含的具體點： ``` EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)'; QUERY PLAN ------------------------------------------------------------------------------------------------------ Seq Scan on polygon_tbl (cost=0.00..1.05 rows=1 width=32) (actual time=0.044..0.044 rows=0 loops=1) Filter: (f1 @> '((0.5,2))'::polygon) Rows Removed by Filter: 4 Total runtime: 0.083 ms ``` 規劃器認為（很正確）這種表太小而干擾索引掃描，所以我們有一個純順序掃描，其中所有行通過過濾條件被拒絕。但是，如果我們強制使用索引掃描，我們看到： ``` SET enable_seqscan TO off; EXPLAIN ANALYZE SELECT * FROM polygon_tbl WHERE f1 @> polygon '(0.5,2.0)'; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------- Index Scan using gpolygonind on polygon_tbl (cost=0.13..8.15 rows=1 width=32) (actual time=0.062..0.062 rows=0 loops=1) Index Cond: (f1 @> '((0.5,2))'::polygon) Rows Removed by Index Recheck: 1 Total runtime: 0.144 ms ``` 在這里，我們可以看到，索引返回一個候選行，這是通過索引條件的重新檢查被拒絕。這是因為 GiST索引對于多邊形封閉測試是"lossy"：它實際上返回帶有重疊目標多邊形的行，然后我們在那些行上進行確切的封閉測試。 `EXPLAIN`有`BUFFERS`選項，`ANALYZE`以獲得更多的運行時間統計： ``` EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000; QUERY PLAN --------------------------------------------------------------------------------------------------------------------------------- Bitmap Heap Scan on tenk1 (cost=25.08..60.21 rows=10 width=244) (actual time=0.323..0.342 rows=10 loops=1) Recheck Cond: ((unique1 < 100) AND (unique2 > 9000)) Buffers: shared hit=15 -> BitmapAnd (cost=25.08..25.08 rows=10 width=0) (actual time=0.309..0.309 rows=0 loops=1) Buffers: shared hit=7 -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1) Index Cond: (unique1 < 100) Buffers: shared hit=2 -> Bitmap Index Scan on tenk1_unique2 (cost=0.00..19.78 rows=999 width=0) (actual time=0.227..0.227 rows=999 loops=1) Index Cond: (unique2 > 9000) Buffers: shared hit=5 Total runtime: 0.423 ms ``` 通過`BUFFERS`提供的數字幫助辨識查詢的哪些部分大多是I/O密集型。請記住，因為`EXPLAIN ANALYZE`實際運行查詢，任何副作用還是一樣會發生，即使無論什么結果查詢可能的輸出都將被丟棄而贊成輸出`EXPLAIN`的數據。如果要分析一個數據修改的查詢，而無需改變你的表，你可以回滾命令到后面，例如： ``` BEGIN; EXPLAIN ANALYZE UPDATE tenk1 SET hundred = hundred + 1 WHERE unique1 < 100; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------- Update on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=14.628..14.628 rows=0 loops=1) -> Bitmap Heap Scan on tenk1 (cost=5.07..229.46 rows=101 width=250) (actual time=0.101..0.439 rows=100 loops=1) Recheck Cond: (unique1 < 100) -> Bitmap Index Scan on tenk1_unique1 (cost=0.00..5.04 rows=101 width=0) (actual time=0.043..0.043 rows=100 loops=1) Index Cond: (unique1 < 100) Total runtime: 14.727 ms ROLLBACK; ``` 如該示例中，當查詢是`INSERT`,`UPDATE`或者`DELETE`命令時，申請表變化的實際工作是由頂層插入、更新、或刪除規劃節點完成的。這個節點下的規劃節點進行定位舊的行和/或計算新數據。所以上面，我們看到了已經看到的相同排序的位表掃描，并且其輸出被傳遞給存儲更新行的更新節點。值得一提的是，雖然修改數據的節點可以采取大量的運行時間（在這里，它消耗了大部分的共享的時間），規劃器目前不添加任何東西的成本來估計說明這項工作。這是因為要做的工作是同樣為了每一個正確的查詢規劃，因此它不影響規劃決定。 `EXPLAIN ANALYZE`顯示的`Total runtime`包括執行器啟動和關閉的時間，以及被激發的任何觸發器運行時間。但它不包括分析、重寫、規劃的時間。執行`BEFORE`觸發器花費的時間，如果有的話，包括在為相關插入，更新或刪除節點的時間內，但執行`AFTER`觸發器的時間花費并不計算在內，因為整個規劃完成之后，才觸發`AFTER`觸發器。單獨顯示每個觸發器花費的總時間（`BEFORE` 或者`AFTER`）。需要注意的是延遲約束觸發器直到事務結束將不會執行，因而不會通過`EXPLAIN ANALYZE`顯示。 ## 14.1.3\. 警告有兩個顯著方式測量運行時間，通過 `EXPLAIN ANALYZE`偏離相同查詢的正常執行。首先，由于沒有輸出行被傳遞到客戶端，不包含網絡傳輸成本和I/O轉換費用。其次，通過`EXPLAIN ANALYZE`增加的測量開銷是巨大的，特別是在慢的`gettimeofday()`操作系統調用機器上。您可以使用 [pg_test_timing](#calibre_link-1203)工具來測量您系統上的定時開銷。 `EXPLAIN`的結果除了在你實際測試的情況之外不能推導出其它的情況；比如，在一個小得像玩具的表上的結果不能適用于大表。規劃器的開銷計算不是線性的，因此它很可能對大些或者小些的表選擇不同的規劃。一個極端的例子是一個只占據一個磁盤頁面的表，在這樣的表上，不管它有沒有索引可以使用，你幾乎都總是得到順序掃描規劃。規劃器知道不管在任何情況下它都要進行一個磁盤頁面的讀取，所以再擴大幾個磁盤頁面讀取以查找索引是沒有意義的。（我們可以從`polygon_tbl`上面的例子中看到）在某些情況中，實際與估計值不能很好的匹配，但沒有什么是真的錯了。出現這樣的一個情況，當規劃節點執行是由`LIMIT`或類似效果而短暫停止。例如，我們以前使用`LIMIT`查詢。 ``` EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000 LIMIT 2; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------- Limit (cost=0.29..14.71 rows=2 width=244) (actual time=0.177..0.249 rows=2 loops=1) -> Index Scan using tenk1_unique2 on tenk1 (cost=0.29..72.42 rows=10 width=244) (actual time=0.174..0.244 rows=2 loops=1) Index Cond: (unique2 > 9000) Filter: (unique1 < 100) Rows Removed by Filter: 287 Total runtime: 0.336 ms ``` 為索引掃描節點的估計成本和行數都被顯示。即使它是運行完畢的。但現實是請求行運行兩個之后限制節點停止，所以實際的行數只有2和，并且運行時間低于成本估算。這不是估計錯誤，由于只有一個差異估計和真實值顯示。合并連接也有可混淆粗心的測量產品。合并連接將停止讀取一個輸入，如果它用盡了其他輸入，并且輸入端的下一個關鍵值大于其他輸入的最后一個關鍵值；在這種情況下，就不可能有更多的匹配，所以不需要掃描第一個輸入的其余部分。這會導致無法讀取所有子節點，有些像那些提到的`LIMIT`結果。此外，如果外部（第一）子節點包含重復鍵值的行，內部（第二個）子節點被備份并重新掃描行匹配鍵值的部分。 `EXPLAIN ANALYZE`計算同一內部行的重復部分，好像他們是真正的附加行。當有許多外部重復部分，為了內部子規劃節點比真實內部關系行數足夠大，則報告的實際行數。 BitmapAnd和BitmapOr節點總是報告自己的實際行數為零，由于實施限制。