GBase 8a MPP Cluster数据库采用分布式大规模并行处理架构，常用于OLAP分析型场景。此类场景中通常基础数据量比较大，不同SQL运行时长差异较大。不同于MYSQL等交易型数据库，其负载多为高并发的短事务类型，慢查询SQL任务可通过设置固定阈值来统一对执行时间过长的SQL进行记录，分析型场景由于业务特点存在SQL正常执行时间从几秒钟到几小时都有可能，因此无法通过简单方式来判断SQL任务是否异常。本文总结了GBase 8a MPP Cluster数据库中SQL运行缓慢的分析排查和优化方法，供其他用户参考。

排查和优化方法

SQL任务历史性能对比分析：

通过开启GBase 8a的audit_log审计日志，可以连续收集周期性任务的执行时间，通过对比相同SQL任务历史执行时长可以判定相同任务SQL长周期内的执行耗时趋势，通过对比发现执行性能异常情况，并进行针对性的分析。如，相同SQL任务在一定周期内执行时间逐渐变长，则需要结合表内数据量变化趋势、SQL任务类型需要访问全量数据还是只访问增量数据等进行分析。

执行计划分析：

对于性能异常的SQL，通常先通过执行计划分析执行步骤是否存在可优化的空间。GBase 8a提供的explain分布式执行计划，可以提供SQL任务的执行顺序和步骤，常见的执行计划中的问题和优化方法包括：

• 避免不合理的动态重分布或者拉复制表降低数据在节点间重分布的代价；

• 检查join列的字段类型，避免因字段类型不一致导致的数据动态重分布；

• 调整不合理的join顺序，避免出现笛卡尔积导致中间结果集过大；

• 评估哈希索引的必要性，去除不必要的哈希索引；

表数据分布分析：

通常表在各节点间的数据分布会影响查询性能，当表数据分布在节点间出现严重的倾斜分布时，不同的节点会因处理的数据量差异较大出现木桶效应。对于数据分布存在严重倾斜的表，可以通过调整表的分布键方式将数据均匀打散，常见的分布键选择策略包括：

• 优先考虑大表间的JOIN，尽量让大表JOIN条件的列为Hash分布列（相关子查询的相关JOIN也可以参考此原则），以使得大表间的JOIN可以直接下发到各节点分布式执行；

• 其次考虑GROUP BY，尽量让GROUP BY带有Hash分布列，让分组聚合一步完成；

• 当有多个join或group列可选择时，优先选择唯一值多（count(distinct)值大）的列做Hash分布列，让数据均匀分布；

• 通常是等值查询的列，并且使用的频率很高的应考虑建立为hash分布列；

通过详细trace日志分析SQL任务瓶颈：

对于一些慢SQL需要详细分析各节点的执行日志，通过日志发现某个节点是否相较其他节点明显执行缓慢，如果存在较慢的节点则进一步排查是什么原因导致的。常见的情况有数据倾斜、并发过高、参数设置不合理、数据分布特征等原因造成。需要根据不同的情况，通过调整表数据分布、设置合理的线程池和并行度（主要排查gbase_parallel_execution、gbase_parallel_degree以及gbase_parallel_max_thread_in_pool等参数）、调整操作系统参数、使用hint影响具体执行计划等方式进行调优。

各节点软硬件参数配置检查：

排查CPU超线程、虚拟内存、透明页和IO调度参数等配置项，查看是否按照厂商建议进行配置。

总结

分布式分析型数据库由于其多节点并行的部署环境及OLAP负载类型复杂的特点，其SQL任务调优相比传统单机交易型数据库更加复杂，需要更加系统的方法论指导，本文的目的在于对日常运维工作中针对GBase 8a数据库的SQL性能分析和优化思路进行总结，期望对从事数据库运维工作的读者提供一些可以借鉴的思路和方法，达到交流思路互相学习的目的。