gaussdb 优化建议

建表

存储选择

表的存储类型及场景

存储类型	适用场景
行存	1. 点查询(返回记录少，基于索引的简单查询)。 2. 增、删、改操作较多的场景。
列存	1. 统计分析类查询 (关联、分组操作较多的场景)。2. 即席查询（查询条件不确定，行存表扫描难以使用索引）

数据分布方式选择

数据存储分布主要是hash 均匀分布和副本分布。

水平分表策略

策略	描述	适用场景
散列（Hash）方式	根据元组中指定字段的值计算出哈希值，根据节点与哈希值的映射关系获得该元组的目标存储位置。	适用于表数据量较大、需要提升查询性能的场景
复制（Replication）方式	将元组复制到所有节点上	适用于表数据量较小、需要提升并发分析性能的场景。

图中显示了两种数据分布的存储情况

合适的分布式列的选择

使用hash分布方式时，需要在建表时指定分布列，不然会导致数据倾斜，数据倾斜会导致系统不稳定。

Hash分布表的分布列选取至关重要，需要满足以下原则：

列值应比较离散，以便数据能够均匀分布到各个DN。例如，考虑选择表的主键为分布列，如在人员信息表中选择身份证号码为分布列。
在满足第一条原则的情况下尽量不要选取存在常量filter的列。例如，表dwcjk相关的部分查询中出现dwcjk的列zqdh存在常量的约束(例如zqdh=’000001’)，那么就应当尽量不用zqdh做分布列。
在满足前两条原则的情况，考虑选择查询中的连接条件为分布列，以便Join任务能够下推到DN中执行，且减少DN之间的通信数据量。

对于Hash分表策略，如果分布列选择不当，可能导致数据倾斜，查询时出现部分DN的I/O短板，从而影响整体查询性能。因此在采用Hash分表策略之后需对表的数据进行数据倾斜性检查，以确保数据在各个DN上是均匀分布的。可以使用以下SQL检查数据倾斜性。

select
xc_node_id, count(1)
from tablename
group by xc_node_id
order by xc_node_id desc;

其中xc_node_id对应DN，一般来说，不同DN的数据量相差5%以上即可视为倾斜，如果相差10%以上就必须要调整分布列。

GaussDB 200支持多分布列特性，可以更好地满足数据分布的均匀性要求。

数据倾斜问题

数据倾斜问题是分布式架构的重要难题，它破坏了MPP架构中各个节点对等的要求，导致单节点（倾斜节点）所存储或者计算的数据量远大于其他节点，所以会造成以下危害：

存储上的倾斜会严重限制系统容量，在系统容量不饱和的情况下，由于单节点倾斜的限制，使得整个系统容量无法继续增长。
计算上的倾斜会严重影响系统性能，由于倾斜节点所需要运算的数据量远大于其它节点，导致倾斜节点降低系统整体性能。
数据倾斜还严重影响了MPP架构的扩展性。由于在存储或者计算时，往往会将相同值的数据放到同一节点，因此当倾斜数据（大量数据的值相同）出现之后，即使我们增加节点，系统瓶颈仍然受限于倾斜节点的容量或者性能。

存储倾斜可以通过使用指定分布列使用数据均匀分布解决，即使通过修改表的分布键，使得数据存储在各个节点上是均衡的，但是在执行查询的过程中，仍然可能出现数据倾斜的问题。在运算过程中某个算子在DN上输出的结果集出现倾斜，从而导致此算子上层的运算出现计算倾斜。一般来说，这是由于在执行过程中，数据重分布导致的。计算上的倾斜依赖GaussDB提出了RLBT(Runtime Load Balance Technology)方案，用以解决运行时的计算倾斜问题，该特性由参数skew_option控制。

skew_option参数说明：控制是否使用优化策略。
该参数属于USERSET类型参数。
取值范围：字符串

off：关闭策略。

normal：采用激进策略。对于不确定是否出现倾斜的场景，认为存在倾斜，并进行相应优化。

lazy：采用保守策略。对于不确定是否出现倾斜场景，认为不存在倾斜，不进行优化。
默认值：normal

查询优化

语句下推优化

目前，GaussDB 200优化器在分布式框架下制定语句的执行策略时，有三种执行计划方式：生成下推语句计划、生成分布式执行计划、生成发送语句的分布式执行计划。

下推语句计划：指直接将查询语句从CN发送到DN进行执行，然后将执行结果返回给CN。
分布式执行计划：指CN对查询语句进行编译和优化，生成计划树，再将计划树发送给DN进行执行，并在执行完毕后返回结果到CN。
发送语句的分布式执行计划：上述两种方式都不可行时，将可下推的查询部分组成查询语句（多为基表扫描语句）下推到DN进行执行，获取中间结果到CN，然后在CN执行剩下的部分。

在第3种策略中，要将大量中间结果从DN发送到CN，并且要在CN运行不能下推的部分语句，会导致CN成为性能瓶颈（带宽、存储、计算等）。在进行性能调优的时候，应尽量避免只能选择第3种策略的查询语句。

执行语句不能下推是因为语句中含有不支持下推的函数或者不支持下推的语法。一般都可以通过等价改写规避执行计划不能下推的问题。

sql编写优化

查询操作

【建议】除ETL程序外，应该尽量避免向客户端返回大量结果集的操作。如果结果集过大，应考虑业务设计是否合理
超过3张表或视图进行关联（特别是full join）时，执行代价难以估算。建议使用WITH TABLE AS语句创建中间临时表的方式增加SQL语句的可读性。
【建议】尽量避免使用笛卡尔积和Full join。这些操作会造成结果集的急剧膨胀，同时其执行性能也很低。
【建议】使用连接操作符“||”替换concat函数进行字符串连接。因为concat函数生成的执行计划不能下推，导致查询性能严重劣化。
【建议】使用下面时间相关的宏替换now函数来获取当前时间。因为now函数生成的执行计划无法下推，导致查询性能严重劣化。
CURRENT_DATE – 获取当前日期，不包含时分秒。
CURRENT_TIME – 获取当前时间，不包含年月日。
CURRENT_TIMESTAMP(n) – 获取当前日期和时间，包含年月日时分秒。说明：n表示存储的毫秒位数。
where子句中的过滤条件，尽量符合单边规则。即把字段名放在比较条件的一边，优化器在某些场景下会自动进行剪枝优化。形如col op expression，其中col为表的一个列，op为‘=’、‘>’的等比较操作符，expression为不含列名的表达式。例如，

SELECT id, from_image_id, from_person_id, from_video_id FROM face_data WHERE current_timestamp(6) - time < '1 days'::interval;

改写为

SELECT id, from_image_id, from_person_id, from_video_id FROM face_data where time >  current_timestamp(6) - '1 days'::interval;

【建议】尽量避免不必要的排序操作。排序需要耗费大量的内存及CPU，如果业务逻辑许可，可以组合使用order by和limit，减小资源开销。GaussDB 200默认按照ASC & NULL LAST进行排序。
【建议】在保障业务逻辑准确的情况下，建议尽量使用UNION ALL来代替UNION。
【建议】如果过滤条件只有OR表达式，可以将OR表达式转化为UNION ALL以提升性能。使用OR的SQL语句经常无法优化，导致执行速度慢。例如，将下面语句

SELECT * FROM scdc.pub_menu
WHERE (cdp= 300 AND inline=301) OR (cdp= 301 AND inline=302) OR (cdp= 302 ANDinline=301);

转换为

SELECT * FROM scdc.pub_menu
WHERE (cdp= 300 AND inline=301)
union all
SELECT * FROM scdc.pub_menu
WHERE (cdp= 301 AND inline=302)
union all
SELECT * FROM tablename
WHERE (cdp= 302 AND inline=301)

【建议】通过游标进行翻页查询，而不是使用LIMIT OFFSET语法，避免多次执行带来的资源开销。游标必须在事务中使用，执行完后务必关闭游标并提交事务。