1 业务现象

GaussDB的总体性能调优思路为性能瓶颈点分析、关键参数调整以及SQL调优。在调优过程中，通过系统资源、吞吐量、负载等因素来帮助定位和分析性能问题，使系统性能达到可接受的范围。

2 技术背景

在明确调优范围后需要对性能做一个整体问题诊断，分析数据库服务器资源消耗情况，再看引发资源瓶颈不优的SQL语句。

不优的SQL语句主要优化的场景一般有两类：单条SQL性能优化和并发SQL的性能优化。其中并发场景的性能优化是要基于单条SQL优化已经完成的前提下进行的！下面详细说明一下相关优化思路。

3 调优思路

3.1 单条SQL的性能优化（简单SQL+复杂SQL）：

3.1.1 对于单表查询的SQL

    1）选择正确的分布列，对于点查SQL选where条件过滤性较好重复值较少的列作为分布列，让数据分布均匀；

    2）在过滤性较好的列上创建索引，确保点查结果集较小的点查SQL使用上索引；

    3）对于group by类大数据量的分组统计，可打开SMP并行和开启向量化引擎来提升性能；

    同时，需要合理判断SQL执行耗时是否正常，如单表点查SQL一般explain analyze耗时在0.5ms左右，explain查看计划有bypass关键字，此类SQL最优的计划是下推至单dn后走索引查询。

3.1.2 对于多表关联的SQL

    1）选择合适的分布列，如果一个SQL的计划中出现streaming关键字，则很有可能表的分布列选择不正确，需要进行分布列调整，分布列的选择原则是DN的各节点数据均匀分布。

    2）选择合适的分布方式，在分布表表的分布列不能完全避免stream的情况下，可以考虑将某些表建成复制表，分布方式的选择原则：

•  复制表（Replication）方式将表中的全量数据在集群的每一个DN实例上保留一份。主要适用于记录集较小的表。这种存储方式的优点是每个DN上都有该表的全量数据，在join操作中可以避免数据重分布操作，从而减小网络开销，同时减少了plan segment(每个plan segment都会起对应的线程)；缺点是每个DN都保留了表的完整数据，造成数据的冗余。一般情况下只有较小的维度表才会定义为Replication表。
•  哈希（Hash）表将表中某一个或几个字段进行hash运算后，生成对应的hash值，根据DN实例与哈希值的映射关系获得该元组的目标存储位置。对于Hash分布表，在读/写数据时可以利用各个节点的I/O资源，大大提升表的读/写速度。一般情况下大表定义为Hash表。
• 范围（Range）和列表（List）分布是由用户自定义的分布策略，根据分布列的取值落入满足一定范围或者具体值的对应目标DN，这两种分布方式便于用户灵活地进行数据管理，但对用户本身的数据抽象能力有一定的要求。

例：a.c1=b.c1 and a.c2=c.c2，如果abc三表都是分布表，则必然出现stream情况，此时为了避免streaming，需要判断a表和c表哪张表更小，将较小的那张表建成复制表，比如c表较小，则此时的分布列选择为a以c1列为分布列，b以c1为分布列，c建成broadcast表。

    3）创建合适的索引

对于最终结果集较小（1/10/100）的SQL：此类SQL一般是有某张表有where条件等值过滤，过滤后结果集很小，然后再去跟其他表关联，这种情况下的最优计划是等值条件过滤的列有索引是通过索引进行的快速过滤，然后与之关联的表关联列上都有索引，通过层层索引过滤后得到最终结果。此类SQL的执行计划中一般都是index scan和nestloop之类的关键字，如果出现seq scan、hash join等关键字很有可能计划不是最优，此时需要进行调整。

    4）对于有较大数据需要计算的SQL，如整表无等值条件关联、统计分析、排序的SQL，需要打开SMP并行和开启向量化引擎

    5）以上都分析好以后，还需要关注表的关联顺序是否正确，原则是哪两个表关联能先过滤较多的数据就哪两个表先关联。

3.1.2、创建索引优化性能：

    1）调大内存参数，set maintenance_work_mem = '8GB';（可根据实际情况调整值大小）

    2）打开表级索引并行创建，alter table test_t1 set (parallel_workers=8);（可根据实际情况调整值大小）

    3）创建索引，create index ……

    4）关闭并行，alter table test_t1 reset parallel_workers;

3.2 并发SQL性能优化

    1）先按照上述3.1节描述的将单条SQL性能优化好，注：并发量较大的情况下复杂SQL也无需开SMP并行，视具体情况分析而定；

    2）根据硬件资源和数据库活跃连接数判断数据库是否到瓶颈，经常碰到并发压力并未到数据库端的情况，实际瓶颈在应用压测机客户端，常碰到的现象有：数据库端CPU、IO压力很低不足50%，数据库活跃连接很少远低于实际并发数，如1000并发时数据库端活跃连接只有百来个甚至更少，此时需要先解决客户端瓶颈问题；

    3）确定瓶颈在数据以后，再根据等待事件、WDR报告等分析具体瓶颈，针对具体情况调整相应内存、IO、计划缓存等相关的参数。

详细的分析思维导图和相关命令可参考整体性能和单语句性能问题

整体性能

   单语句性能

3.3 对应的一些定位sql语句如下

定位sql语句需要开启相关GUC参数：

gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "track_activities='on'"
gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "enable_resource_track='on'"
gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "enable_instr_track_wait = on"
gs_guc reload -Z coordinator -Z datanode  -N all -I all -c "track_sql_count = on"

• 线程池中工作线程及会话的状态信息

select node_name,session_info from dbe_perf.global_threadpool_status order by 1;

•  查询本节点活跃会话状态及等待事件

select sample_time,substring(unique_query,0,100),application_name,wait_status 
from dbe_perf.local_active_session where wait_status not in (''none'',''wait cmd'') 
order by start_time desc;

• 查询本节点活跃会话等待事件统计

select wait_status,count(*) from dbe_perf.local_active_session group by wait_status order by 2 desc;

• 查询耗时sql

select query from dbe_perf.statement where user_name!='omm' order by cpu_time desc;

• 查询采样SQL平均耗时及最大耗时

select node_name,unique_sql_id,substring(query,0,100),total_elapse_time/n_calls/1000 as single_time_consumption,max_elapse_time
 from dbe_perf.summary_statement where n_calls>1 
and max_elapse_time > 1000000;

• 查询会话sql个数抓取：

select query,count(query) from pg_stat_activity where state != 'idle' group by query;

• 指定节点查询特定sql历史等待事件

select wait_status, count(*) from gs_asp where unique_query_id=xxxx group by wait_status;
select wait_status, application_name, count(*) from gs_asp where unique_query_id=xxxx group by wait_status,application_name';

•  清空系统视图：

select reset_unique_sql('GLOBAL','ALL',0);

• 查询连接数是否均匀：

select coorname,count(*) from pgxc_stat_activity where query like '%xxxx%' group by coorname;

4 简单总结

在明确调优范围后，需要分析服务器资源信息以及资源使用情况，再分析不优的SQL语句，使用对应的一些定位sql语句找到性能问题。