GreenPlum的SQL优化方案

GreenPlumn的SQL语句查询优化数据库查询预准备1.VACUUMvacuum只是简单的回收空间且令其可以再次使用，没有请求排它锁，仍旧可以对表读写vacuumfull执行更广泛的处理，包括跨块移动行，以便把表压缩至使用最少的磁盘块数目存储。相对vacuum要慢，而且会请求排它锁。定期执行：在日常维护中，需要对数据字典定期执行vacuum，可以每天在数据库空闲的时候进行。然后每隔一段较长时间（两三个月）对系统表执行一次vacuumfull，这个操作需要停机，比较耗时，大表可能耗时几个小时。reindex:执行vacuum之后,最好对表上的索引进行重建2.ANALYZE命令：analyze[talbe[(column,..)]]收集表内容的统计信息，以优化执行计划。如创建索引后，执行此命令，对于随即查询将会利用索引。自动统计信息收集在postgresql.conf中有控制自动收集的参数gp_autostats_mode设置，gp_autostats_mode三个值：none、no_change、on_no_stats（默认）onone：禁止收集统计信息oonchange：当一条DML执行后影响的行数超过gp_autostats_on_change_threshold参数指定的值时，会执行完这条DML后再自动执行一个analyze的操作来收集表的统计信息。ono_no_stats：当使用createtalbeasselect、insert、copy时，如果在目标表中没有收集过统计信息，那么会自动执行analyze来收集这张表的信息。gp默认使用on_no_stats，对数据库的消耗比较小，但是对于不断变更的表，数据库在第一次收集统计信息之后就不会再收集了。需要人为定时执行analyze.如果有大量的运行时间在1分钟以下的SQL，你会发现大量的时间消耗在收集统计信息上。为了降低这一部分的消耗，可以指定对某些列不收集统计信息，如下所示：1.createtabletest(idint,nametext,notetext);上面是已知道表列note不需出现在join列上，也不会出现在where语句的过滤条件下，因为可以把这个列设置为不收集统计信息：1.altertabletestalternoteSETSTATISTICS0;3.EXPLAIN执行计划显示规划器为所提供的语句生成的执行规划。cost：返回第一行记录前的启动时间，和返回所有记录的总时间（以磁盘页面存取为单位计量）rows：根据统计信息估计SQL返回结果集的行数width：返回的结果集的每一行的长度，这个长度值是根据pg_statistic表中的统计信息来计算的。4.两种聚合方式hashaggregate根据groupby字段后面的值算出hash值，并根据前面使用的聚合函数在内存中维护对应的列表，几个聚合函数就有几个数组。相同数据量的情况下，聚合字段的重复度越小，使用的内存越大。groupaggregate先将表中的数据按照groupby的字段排序，在对排好序的数据进行全扫描，并进行聚合函数计算。消耗内存基本是恒定的。选择在SQL中有大量的聚合函数，groupby的字段重复值比较少的时候，应该用groupaggregate5.关联分为三类：hashjoin、nestloopjoin、mergejoin，在保证sql执行正确的前提下，规划器优先采用hashjoin。hashjoin:先对其中一张关联的表计算hash值，在内存中用一个散列表保存，然后对另外一张表进行全表扫描，之后将每一行与这个散列表进行关联。nestedloop:关联的两张表中的数据量比较小的表进行广播，如笛卡尔积：select*fromtest1，test2mergejoin:将两张表按照关联键进行排序，然后按照归并排序的方式将数据进行关联，效率比hashjoin差。fullouterjoin只能采用mergejoin来实现。关联的广播与重分布解析P133，一般规划器会自动选择最优执行计划。有时会导致重分布和广播，比较耗时的操作6.重分布一些sql查询中，需要数据在各节点重新分布，受制于网络传输、磁盘I/O，重分布的速度比较慢。关联键强制类型转换一般，表按照指定的分布键作hash分部。如果两个表按照id:intege、id:numericr分布，关联时，需要有一个表id作强制类型转化，因为不同类型的hash值不一样，因而导致数据重分布。关联键与分部键不一致groupby、开窗函数、groupingsets会引发重分布查询优化通过explain观察执行计划，从而确定如果优化SQL。1.explain参数显示规划器为所提供的语句生成的执行规划。cost：返回第一行记录前的启动时间，和返回所有记录的总时间（以磁盘页面存取为单位计量）rows：根据统计信息估计SQL返回结果集的行数width：返回的结果集的每一行的长度，这个长度值是根据pg_statistic表中的统计信息来计算的。2.选择合适分布键分布键选择不当会导致重分布、数据分布不均等，而数据分布不均会使SQL集中在一个segment节点的执行，限制了gp整体的速度。使所有节点数据存放是均匀的，数据分布均匀才能充分利用多台机器查询，发挥分布式的优势。join、开窗函数等尽量以分布键作为关联键、分区键。尤其需要注意的是join、开窗函数会依据关联键、分区键做重分布或者广播操作，因而若分布键和关联键不一致，不论如何修改分布键，也是需要再次重分布的。尽量保证where条件产生的结果集的存储也尽量是均匀的。查看某表是否分布不均：selectgp_segment_id,count(*)fromfact_tablegroupbygp_segment_id在segment一级，可以通过selectgp_segment_id,count(*)fromfact_tablegroupbygp_segment_id的方式检查每张表的数据是否均匀存放在系统级，可以直接用df-h或du-h检查磁盘或者目录数据是否均匀查看数据库中数据倾斜的表首先定义数据倾斜率为：最大子节点数据量/平均节点数据量。为避免整张表的数据量为空，同时对结果的影响很小，在平均节点数据量基础上加上一个很小的值，SQL如下：SELECTtabname,max(SIZE)/(avg(SIZE)+0.001)ASmax_div_avg,sum(SIZE)total_sizeFROM(SELECTgp_segment_id,oid::regclasstabname,pg_relation_size(oid)SIZEFROMgp_dist_random('pg_class')WHERErelkind='r'ANDrelstorageIN('a','h'))tGROUPBYtabnameORDERBY2DESC;3.分区表按照某字段进行分区，不影响数据在数据节点上的分布，但是，仅在单个数据节点上，对数据进行分区存储。可以加快分区字段的查询速度。4.压缩表对于大AO表和分区表使用压缩，以节省存储空间并提高系统I/O，也可以在字段级别配置压缩。应用场景：不需要对表进行更新和删除操作访问表的时候基本上是全表扫描，不需要建立索引不能经常对表添加字段或者修改字段类型5.分组扩展Greenplum数据库的GROUPBY扩展可以执行某些常用的计算，且比应用程序或者存储过程效率高。GROUPBYROLLUP(col1,col2,col3)GROUPBYCUBE(col1,col2,col3)GROUPBYGROUPINGSETS((col1,col2),(col1,col3))ROLLUP对分组字段（或者表达式）从最详细级别到最顶级别计算聚合计数。ROLLUP的参数是一个有序分组字段列表，它计算从右向左各个级别的聚合。例如ROLLUP(c1,c2,c3)会为下列分组条件计算聚集：(c1,c2,c3)(c1,c2)(c1)()CUBE为分组字段的所有组合计算聚合。例如CUBE(c1,c2,c3)会计算一下聚合：(c1,c2,c3)(c1,c2)(c2,c3)(c1,c3)(c1)(c2)(c3)()GROUPINGSETS指定对那些字段计算聚合，它可以比ROLLUP和CUBE更精确地控制分区条件。6.窗口函数窗口函数可以实现在结果集的分组子集上的聚合或者排名函数，例如sum(population)over(partitionbycity)。窗口函数功能强大，性能优异。因为它在数据库内部进行计算，避免了数据传输。窗口函数row_number()计算一行在分组子集中的行号，例如row_number()over(orderbyid)。如果查询计划显示某个表被扫描多次，那么通过窗口函数可能可以降低扫描次数。窗口函数通常可以避免使用自关联。7.列存储和行存储列存储亦即同一列的数据都连续保存在一个物理文件中，有更高的压缩率，适合在款表中对部分字段进行筛选的场景。需要注意的是：若集群中节点较多，而且表的列也较多，每个节点的每一列将会至少产生一个文件，那么总体上将会产生比较多的文件，对表的DDL操作就会比较慢。在和分区表使用时，将会产生更多文件，甚至可能超过linux的文件句柄限制，要尤其注意。行存储：如果记录需要update/delete，那么只能选择非压缩的行存方式。对于查询，如果选择的列的数量经常超过30个以上的列，那么也应该选择行存方式。列存储：如果选择列的数量非常有限，并且希望通过较高的压缩比换取海量数据查询时的较好的IO性能，那么就应该选择列存模式。其中，列存分区表，每个分区的每个列都会有一个对应的物理文件，所以要注意避免文件过多，导致可能超越linux上允许同时打开文件数量的上限以及DDL命令的效率很差。8.函数和存储过程虽然支持游标但是，尽量不要使用游标方式处理数据，而是应该把数据作为一个整体进行操作。9.索引使用如果是从超大结果集合中返回非常小的结果集（不超过5%），建议使用BTREE索引（非典型数据仓库操作）表记录的存储顺序最好与索引一致，可以进一步减少IO（好的indexcluster）where条件中的列用or的方式进行join，可以考虑使用索引键值大量重复时，比较适合使用bitmap索引有关索引使用的测试见GP索引调优测试–基本篇和GP索引调优测试–排序篇。10.NOTIN在gp4.3中已经进行了优化，采用hashleftantisemijoin进行连接。以下只针对gp4.1及之前o有notin的SQL，都会采用笛卡尔积来执行，采用nestedjoin，效率极差onotin==》改用leftjoin去重后的表关联来实现o例子oselect*fromtest1wherecol1notin(selectcol2fromtest1)改为select*fromtest1aleftjoin(selectcol2fromtest1groupbycol2)bona.col1=b.col2whereb.col2isnull运行时间由30多秒提升至92毫秒。11.聚合函数太多一条SQL中聚合函数太多，而且可能由于统计信息不够详细或者SQL太负责，错选hashaggregate来执行，导致内存不足。解决方法：o拆分成多个SQL来执行，减少hashaggregate使用的内存o执行enable_hashagg=off，把hashaggregate参数关掉，强制不采用。将会采用groupaggregate，这样排序时间会长一些，但是内存可控，建议采用这种方式比较简单。12.资源队列数据写入、查询分别使用不同的用户，GP创建用户时为不同用户指定不同的资源队列。13.其它优化技巧用groupby对distinct改写，因为DISTINCT要进行排序操作用UNIONALL加GROUPBY的方式对UNION改写尽量使用GREENPLUM自身