Content      ..     7      8      9     

Greenplum Database (V6.2.1) - 9

Greenplum Database 管理员指南 V6.2.1

从执行计划可以看到，Orca优化器，根据失真的统计信息生成了错误的执行计划，

在扫描完数据之后，就使用a字段进行数据重分布，这注定会发生计算倾斜。执行计划

中，选择了GroupAggregate算子，而不是HashAggregate算子来完成Group By

的计算，这个问题不是本节的重点，结尾处会再来优化这个问题，下面先看看这个缺省

的执行计划的实际执行情况：

从EXPLAIN ANALYZE的输出可以看出，表扫描之后重分布算子就花费了22秒的时间。

接下来对执行计划进行适当的干预，避免出现计算倾斜，设置如下的GUC参数：

SET optimizer_force_multistage_agg TO ON;

此时，执行计划变为：

图形化的执行计划为：

版权所有：Esena(陈淼 ) 编写：陈淼 - 400 -

Greenplum Database 管理员指南 V6.2.1

从执行计划可以看出，扫描完数据之后，先进行了本地AGG操作，这样就避免的计

算倾斜。实际执行情况：

整个SQL的耗时，从52秒下降到了7秒。

最后，将GroupAggregate的问题进行一下优化：

设置如下的GUC参数：

SET optimizer_force_multistage_agg TO ON;

SET optimizer_enable_groupagg TO OFF;

再看一下执行计划：

图形化的执行计划为：

实际执行情况：

版权所有：Esena(陈淼 ) 编写：陈淼 - 401 -

Greenplum Database 管理员指南 V6.2.1

整个SQL的耗时，下降到了0.9秒，这是因为，在大多数情况下GroupAgg的性能

远不如HashAgg的性能，根本原因是Sort的计算复杂度是O(NlnN)，而Hash的计算

复杂度为O(N))。

编者无法进行大篇幅的举例说明，毕竟真实生产情况下，计算倾斜的情况比这个例

子要复杂的多，不过，编者希望这个例子能成为一个学习和解决计算倾斜的入门示例。

在官方文档中，还介绍了如何如何通过gpssh工具来查看每个Primary的溢出文

件情况，以此来分析发生倾斜时，哪些Primary因为内存资源的不足而导致大量的产

生溢出文件到磁盘上，实际上，编者认为，直接通过gp_toolkit的几个workfile的

视图就可以很好的发现溢出文件的问题：gp_workfile_entries、

gp_workfile_usage_per_query、gp_workfile_usage_per_segment。

分区

合理的分区，将有助于减少相关查询需要扫描的数据量，也将有助于对数据进行周

期性管理。每个叶子分区，都是一个独立的数据表，在每个Instance上，数据都存储

在独立的数据文件中。分区与分布，是完全不相关的两个概念，分布，是数据在多个

Instance之间分散，分区，在每个Instance看来，数据被拆分存储在多个独立的数

据库表中。如果对于分库分表能够理解的话，分布类似于分库，分区类似于分表。

不过，如果没有任何的分区裁剪，而是做全表查询，则，分区表的性能会低于同样

数据的非分区表，因为需要打开更多的文件，以及对扫描的结果进行合并。这就如同列

存表与行存表，如果要查询所有的字段，列存表的性能会低于同样数据的行存表，因为

需要打开更多的文件，甚至还需要把不同字段的数据重新组织为ROW。

下面是分区的最佳实践：

 只对特别大的表进行分区--这是所有条件中必须满足的条件，不满足该条件的任

何表，都不应该进行分区。永远不要对小表进行分区，哪怕它的表结构和应用场景

非常的具有周期性和规律性。

版权所有：Esena(陈淼 ) 编写：陈淼 - 402 -

Content      ..     7      8      9