Greenplum数据库性能下降时的调优方向汇总

一、硬件是否出现问题

服务器是否宕机

磁盘、内存性能是否正常

        数据库的性能，归根到底就是依赖于硬件的性能，其中磁盘、内存的尤为重要。

网络是否畅通

        分布式数据库集群在处理数据时，会产生大量的内部数据传输。GP官方建议内部网络为万兆网，否则会影响集群性能。当网络存在拥堵，无疑很容易影响数据库性能。

是否有失败的节点

        GP不同的配置模型，在集群掉节点时，产生的性能下降有所一样。但无论怎么样，由于木桶效应，性能肯定会下降一大截。

磁盘空间使用比例是否过大

        无论什么是否，GP数据库的磁盘使用率不能超过70%，GP数据库需要周转空间来处理数据，当磁盘使用率超过70%会对性能产生明显影响。

二、资源的分配和竞争是否合理

在系统中限制活动的查询

        并发的查询并非越多整体效率越高

限制特定用户查询的能力（成本、优先级和内存）

        按照业务的优先级，为优先级高的任务让路。限制优先级低用户查询的能力。

避免并发的会话在同一时间更新相同的数据

        合理安排任务调度，避免并发的会话在同一时间更新相同的数据。

三、数据库表检查

数据库表统计信息是否缺失

        统计信息的缺失会导致执行计划错乱，甚至会对一张大表进行广播，产生大量的磁盘读写、网络流量。

数据库表是否存在倾斜

        由于木桶原理，查询的处理效率取决于性能最差的那台机。数据倾斜会导致某些机器负载过高，从而影响整体性能。

四、查询时是否存在计算倾斜

       计算倾斜比较难发现，例如在关联时，关联的字段唯一性不高，并且用了这个字段做了重分布，就会出现计算倾斜。

五、重点SQL脚本是否能优化

       查看执行计划，分析查询是否存在优化点。例如不同表之间用来连接的字段是否使用相同类型；子查询是否可先用限定条件；如果使用分区，验证是否实现了分区消除；解释计划是否显示带有大量行的广播移动等。

六、数据库设计是否能优化

是否使用星型模型来设计数据库表
数据库表的存储方式

        根据不同的使用场景，为数据库表选择不同的存储方式，选择不同压缩层次压缩级别，决定是否进行选择分区及分区的层次

数据字段的类型选择

        选择尽可能最小尺寸来填充数据

        字符串数据用varchar或者text类型