我们先看看性能调优的思路，遇到性能问题，先确定性能调优的范围，观察是否是某个系统资源达到瓶颈，或者是否存在SQL阻塞或慢SQL。如果是系统资源类问题，我们通过系统调优来进行诊断和优化；如果是SQL层面问题，通过SQL调优进行诊断和优化，最终看优化后效果是否满足业务需求，如果一次优化不能达成预期，则需要多轮迭代，最终达成目标。
我们看一下数据库系统整体性能问题的定位思路，先判断是数据库层面问题还是其他层面问题，其他层面问题是否是节点上其他进程引起的数据库性能下降，或者是操作系统参数配置不当引起的。若是数据库层面问题，需要对数据库占用的系统资源信息、数据库内核资源、主备状况等进行综合分析，最后确认问题根因。
在分析单条SQL语句性能时，可以通过使用视图statement_history或者statement，查询语句每个阶段执行的时间消耗，确定语句执行的性能瓶颈。statement_history记录了执行时间超过阈值(log_min_duration_statement，默认3 s)的详细SQL信息，包含计划生成时间、执行时间、锁等待时间等信息；statement记录了SQL按照unique_sql_id归一化的执行信息，包括执行次数、总的执行时间、访问数据量、内存使用等信息。然后通过等待事件视图，查询阻塞会话和对象；最后通过执行计划，获取更细粒度的算子执行情况，如是否走索引、走正确的索引、分布式执行算子stream是否涉及广播等。
讲到GaussDB全量SQL和慢SQL，我们看一下他们包含哪些内容。GaussDB的多维度指标监控采集粒度不同，对系统性能的影响也不同，主要分为三个级别进行采集。
L0级别基本不影响业务执行，采集信息包括实例信息、语句信息、元组、缓存、执行时间等； L1级别对系统稍微有影响，但可接受，这也是业务上线默认推荐的配置，主要包括执行计划信息和锁的统计次数； 开启L2会对系统带来很大影响，通常用在问题定位，包括细粒度锁信息和等待时间等。
下面介绍两个案例。第一个是应用升级后引起了性能剧烈波动，我们先观察一下实例整体执行的时间，看看在哪一步消耗的比重最高，通过归一化视图观察单个SQL，看每一步的执行消耗，发现是在网络发送部分引起的，我们把应用侧进行替换，应用程序更新后这个问题就解决了。
第二个是集群整体性能劣化。我们先观察CN上线程等待状态，发现有些节点等待次数超高；我们在异常节点上分析等待事件，发现wal sync等待的时间较高，通过对比正常节点，确认该节点上存在wal sync的问题；最后分析出主备间日志LSN分片差异较大，一直在进行回放，影响系统整体性能。
最后介绍一下GaussDB两个自调优利器，分别是索引推荐和分布键推荐，主要用于提供高效推荐。比如索引推荐，可以帮助用户根据业务负载自动推荐合适的索引组合，识别冗余索引和无效索引；在推荐索引时，同时输出正向提升SQL信息和负向提升SQL信息，帮助用户来决策是否使用推荐的索引。
