PostgreSql的Explain命令详解

使用EXPLAIN

PostgreSQL为每个收到的查询设计一个查询规划。选择正确的匹配查询结构和数据属性的规划对执行效率是至关重要要的，所以系统包含一个复杂的规划器来试图选择好的规划。你可以使用EXPLAIN命令查看查询规划器创建的任何查询。阅读查询规划是一门艺术，需要掌握一定的经验，本节试图涵盖一些基础知识。

以下的例子来自PostgreSQL 9.3开发版。

EXPLAIN基础

查询规划是以规划为节点的树形结构。树的最底节点是扫描节点：他返回表中的原数据行。

不同的表有不同的扫描节点类型：顺序扫描，索引扫描和位图索引扫描。

也有非表列源，如VALUES子句并设置FROM返回，他们有自己的扫描类型。

如果查询需要关联，聚合，排序或其他操作，会在扫描节点之上增加节点执行这些操作。通常有不只一种可能的方式做这些操作，所以可能出现不同的节点类型。

EXPLAIN的输出是每个树节点显示一行，内容是基本节点类型和执行节点的消耗评估。可能会楚翔其他行，从汇总行节点缩进显示节点的其他属性。第一行（最上节点的汇总行）是评估执行计划的总消耗，这个值越小越好。

下面是一个简单的例子：

因为这个查询没有WHERE子句，所以必须扫描表中的所有行，所以规划器选择使用简单的顺序扫描规划。括号中的数字从左到右依次是：

• 评估开始消耗。这是可以开始输出前的时间，比如排序节点的排序的时间。
• 评估总消耗。假设查询从执行到结束的时间。有时父节点可能停止这个过程，比如LIMIT子句。
• 评估查询节点的输出行数，假设该节点执行结束。
• 评估查询节点的输出行的平均字节数。

这个消耗的计算依赖于规划器的设置参数，这里的例子都是在默认参数下运行。

需要知道的是：上级节点的消耗包括其子节点的消耗。这个消耗值只反映规划器关心的内容，一般这个消耗不包括将数据传输到客户端的时间。

评估的行数不是执行和扫描查询节点的数量，而是节点返回的数量。它通常会少于扫描数量，因为有WHERE条件会过滤掉一些数据。理想情况顶级行数评估近似于实际返回的数量

回到刚才的例子，表tenk1有10000条数据分布在358个磁盘页，评估时间是（磁盘页*seq_page_cost）+（扫描行*cpu_tuple_cost）。默认seq_page_cost是1.0，cpu_tuple_cost是0.01，所以评估值是(358 * 1.0) + (10000 * 0.01) = 458

 

现在我们将查询加上WHERE子句：

查询节点增加了“filter”条件。这意味着查询节点为扫描的每一行数据增加条件检查，只输入符合条件数据。评估的输出记录数因为where子句变少了，但是扫描的数据还是10000条，所以消耗没有减少，反而增加了一点cup的计算时间。

这个查询实际输出的记录数是7000，但是评估是个近似值，多次运行可能略有差别，这中情况可以通过ANALYZE命令改善。

 

现在再修改一下条件

查询规划器决定使用两步规划：首先子查询节点查看索引找到符合条件的记录索引，然后外层查询节点将这些记录从表中提取出来。分别提取数据的成本要高于顺序读取，但因为不需要读取所有磁盘页，所以总消耗比较小。（其中Bitmap是系统排序的一种机制）

 

现在，增加另一个查询条件：

增加的条件stringu1=\'xxx\'减少了输出记录数的评估，但没有减少时间消耗，应为系统还是要查询相同数量的记录。请注意stringu1不是索引条件。

 如果在不同的字段上有独立的索引，规划器可能选择使用AND或者OR组合索引：

 这个查询条件的两个字段都有索引，索引不需要filre。

 

下面我们来看看LIMIT的影响：

这条查询的where条件和上面的一样，只是增加了LIMIT，所以不是所有数据都需要返回，规划器改变了规划。在索引扫描节点总消耗和返回记录数是运行玩查询之后的数值，但Limit节点预期时间消耗是15，所以总时间消耗是15.增加LIMIT会使启动时间小幅增加（0.25->0.29）。

 

来看一下通过索引字段的表连接：

这个规划中有一个内连接的节点，它有两个子节点。节点摘要行的缩进反映了规划树的结构。最外层是一个连接节点，子节点是一个Bitmap扫描。外部节点位图扫描的消耗和记录数如同我们使用SELECT...WHERE unique1 < 10，因为这时t1.unique2 = t2.unique2还不相关。接下来为每一个从外部节点得到的记录运行内部查询节点。这里外部节点得到的数据的t1.unique2值是可用的，所以我们得到的计划和SELECT...WHEREt2.unique2=constant的情况类似。（考虑到缓存的因素评估的消耗可能要小一些）

外部节点的消耗加上循环内部节点的消耗（39.47+10*7.91）再加一点CPU时间就得到规划的总消耗。

 

再看一个例子：

条件t1.hundred<t2.hundred不在tenk2_unique2索引中，所以这个条件出现在连接节点中。这将减少连接节点的评估输出记录数，但不会改变子节点的扫描数。

注意这次规划器选择使用Meaterialize节点，将条件加入内部节点，这以为着内部节点的索引扫描只做一次，即使嵌套循环需要读取这些数据10次，Meterialize节点将数据保存在内存中，每次循环都从内存中读取数据。

 

如果我们稍微改变一下查询，会看到完全不同的规划：

这里规划器选择使用hash join，将一个表的数据存入内存中的哈希表，然后扫描另一个表并和哈希表中的每一条数据进行匹配。

注意缩进反应的规划结构。在tenk1表上的bitmap扫描结果作为Hash节点的输入建立哈希表。然后Hash Join节点读取外层子节点的数据，再循环检索哈希表的数据。

 

另一个可能的连接类型是merge join：

  Merge Join需要已经排序的输入数据。在这个规划中按正确顺序索引扫描tenk1的数据，但是对onek表执行排序和顺序扫描，因为需要在这个表中查询多条数据。因为索引扫描需要访问不连续的磁盘，所以索引扫描多条数据时会频繁使用排序顺序扫描（Sequential-scan-and-sort）。

有一种方法可以看到不同的规划，就是强制规划器忽略任何策略。例如，如果我们不相信排序顺序扫描（sequential-scan-and-sort）是最好的办法，我们可以尝试这样的做法：

显示测结果表明，规划器认为索引扫描比排序顺序扫描消耗高12%。当然下一个问题就是规划器的评估为什么是正确的。我们可以通过EXPLAIN ANALYZE进行考察。

 

EXPLAIN ANALYZE

通过EXPLAIN ANALYZE可以检查规划器评估的准确性。使用ANALYZE选项，EXPLAIN实际运行查询，显示真实的返回记录数和运行每个规划节点的时间，例如我们可以得到下面的结果：

注意，实际时间(actual time)的值是已毫秒为单位的实际时间，cost是评估的消耗，是个虚拟单位时间，所以他们看起来不匹配。

通常最重要的是看评估的记录数是否和实际得到的记录数接近。在这个例子里评估数完全和实际一样，但这种情况很少出现。

 

某些查询规划可能执行多次子规划。比如之前提过的内循环规划（nested-loop），内部索引扫描的次数是外部数据的数量。在这种情况下，报告显示循环执行的总次数、平均实际执行时间和数据条数。这样做是为了和评估值表示方式一至。由循环次数和平均值相乘得到总消耗时间。

 

某些情况EXPLAIN ANALYZE会显示额外的信息，比如sort和hash节点的时候：