第二章 SQL命令参考-EXPLAIN

EXPLAIN

Shows thequery plan of a statement.

概要

EXPLAIN[ANALYZE] [VERBOSE] statement

描述

EXPLAIN显示了Greenplum的策划者生成用于提供语句的查询计划。查询计划节点树计划。计划中的每个节点都代表一个单_的操作，如表扫描，连接，聚集或排序。

计划应当从下往上每个节点馈送行到直接上面的节点可以读取。一个计划的底部节点通常是表扫描操作（顺序，索引或位图索引扫描）。如果查询需要连接，聚集，或者排序（或对原行等操作），那么就会出现扫描节点之上额外的节点来执行这些操作。最上面的计划节点通常是Greenplum数据移动节点（重新分配，明确再分发，广播，或收集动作）。这些负责查询处理期间移动段实例之间的行的操作。

在计划树上explain的每个节点都有_行输出结果，显示基本的节点类型以及以下的成本估计，策划者为规划节点的执行制作：

•    Cost-磁盘页面文件的读取单位;也就是说，1.0等于读取一个顺序磁盘页面。第一个估计是启动成本（获得第_行的费用），第二个是总成本（获得所有行的费用）。需要注意的是总成本假定所有行将被检索，这可能不总是这样的情况（例如使用了limit）。

•    Rows-规划节点输出的总行数。这个数通常比规划节点实际处理或扫描的实际行数少，反映任何WHERE子句的条件的估计的选择性。理想的是，顶层节点估算将近似于实际返回，更新或查询所删除的行的数量。

•    width — total bytes of all the rows output bythis plan node.

•    Width-所有的这个规划节点输出的行的总字节数。

要注意的是上位节点的成本包括其所有子节点的成本是重要的。该计划的最顶层节点具有计划预计总执行成本。这是此数字，规划器试图最小化。同样重要的是要认识到这个开销只反映事物查询优化器关心。特别是，成本不考虑花费发送结果行到客户端的时间。

EXPLAIN分析原因的语句被实际执行，而不仅仅是规划。在EXPLAIN ANALYZE计划显示与规划师的估算值的实际效果。这是看到规划器的预期是否和现实相近很有帮助。除了在解释计划中显示的信息，EXPLAIN分析_下就会显示以下附加信息：

•的总时间（毫秒）所花费的运行查询。

•在计划节点操作中涉及的区段数。只有区段返回的行数才被记录。

•一个区段的操作所能产生的最大的行数。

如果多段产生的行数目相等，则选择一个结束时间最长的。

•在操作中所产生行数最多的区段的段id号。

•对于相关操作，使用的操作。如果work_mem不足以在存储器执行操作，该计划将显示了多少数据溢出到磁盘和多少越过了所必需的最低执行段相关的数据。 例如：

例如：

Work_mem used: 64K bytes avg, 64K bytesmax (seg0).

Work_mem wanted: 90K bytes avg, 90K bytesmax (seg0) to abate workfile

I/O affecting 2 workers.

[segO] pass 0: 488 groups made from 488rows; 263 rows written to

workfile

[seg0] pass 1:263 groups made from 263 rows

•    重要提示：请记住，该语句实际执行时，EXPLAIN ANALYZE使用。尽管EXPLAIN分析_下就会抛弃任何SELECT会返回任何输出，但是其它查询的副作用还是_样会发生。如果你想使用一个DML语句EXPLAIN ANALYZE而且还不想让查询影响你的数据，使用这种方法：

BEGIN;

EXPLAIN ANALYZE …；

ROLLBACK;

parameter  name

T

预处理语句的名称

 parameter

parameter 传递给准备好的语句的实际值。这必须是产生一个值，该值与此parameter 的数据类型兼容，因为在创建准备语句时确定的表达式。

Notes

为了让查询优化器优化查询的时候做出合理的判断，Analyze语句应该运行，以记录有关数据在表中的分布的统计信息。如果没有这样做（或者如果数据的表格中的统计分布自ANALYZE上次运行时间显著改变），估计的成本不太符合查询的实际性能，因此较差的查询方案可以选择。

有关查询分析的详细信息，请参阅“查询剖析”，在Greenplum的数据库管理员指南。