GBase 8a数据库集群，用户发现业务性能变慢，绝大部分都是环境和业务SQL原因，比如服务器硬件故障，或者业务并发太高，数据量太大，或者SQL编写的方式没有优化等。
一、先排除硬件和环境原因
1、磁盘性能差
磁盘损坏
首先确认操作系统日志是否已经报错，查看/var/log/messages或者归档日志，查看是否有磁盘相关的报错，包括扇区类 sector，文件系统类 ext4 、xfs、ext3报错等。基本都包含 sda, sdb等， 或者 err字样。
举例如下：
kernel: [29652410.762413] end_request: critical target error, dev sdb, sector 9771301434
kernel: [29652404.273769] sd 0:0:0:1: [sdb] Add. Sense: Unrecovered read errorload kernel: EXT4-fs warning (device sdb4):ext4_dx_add_entry:Directory index full！磁盘性能问题
可以通过fio 做磁盘随机读写性能测试。如果执行期间部分节点这样，那就可能是部分机器性能不均衡导致。
2、内存不足
出现了SWAP. 这个可以通过在每个节点执行 free 检查。
3、网络问题
现场出现过网卡故障，导致降速成百兆的情况，或者丢包严重。已经出现过几次某台服务器网卡降速，导致整体性能下降。重启网卡后解决。
4、CPU问题
出现过CPU降频，甚至频率不定的情况。 降频可以通过去掉节能模式，启用长期性能模式解决，频率故障那个是更换了CPU。
二、业务问题
1、涉及的表数据量
表数据量很大，耗时肯定增加。
2、业务表在join等操作生成的中间结果，数据量大
比如大表关联，或者多级关联。现场出现过几万的表，在进行多个表的join后，结果集达到1万亿行的情况。
3、在等待锁。
有其他业务拿到了锁，需要等待。可以通过 gcadmin showlock 查看锁占用情况。
也可以通过show detail processlist 查看当前SQL的锁情况。
4、业务繁忙，占用资源高
通过 show processlist 查看当前正在跑的SQL，是不是很多。
通过nmon、iostat等查看磁盘使用繁忙程度。
三、优化问题
1、数据倾斜
主要是分布列或者group的第一个列重复值非常高，导致数据在某1个或几个上出现倾斜，导致虽然节点很多，但性能依然很慢。
2、没有并行
包括系统并发太高，导致后面的SQL没有更多的线程可用，导致内部串行执行。具体参考数据库参数配置 gbase_parallel_degree参数。
也可能是某些算子或函数，数据库内部当前版本没有实现并行，这个需要咨询厂商判断。
3、算法选择不对
数据库内部评估采样选择算法时出现失误，比如group时。此时可以人工设置参数(通过hint)
4、笛卡尔积
这个类似业务问题，区别是这个是SQL书写问题，是可以优化的。那个是业务本身就是结果集大。
5、内部逻辑等待
比如在等其它进程释放锁，特别是DML 和 DQL之间。 新版本集群已经支持DQL不再卡住DML的追加(insert load)模式，但依然会阻塞update等。
或者你在delete或者drop表，但有个该表的长查询在跑，也需要等待其执行完毕。
6、网络故障
节点网络故障，会在某些情况下出现长时间等待，而默认数据库读写超时参数是100万秒。 这个需要业务根据实际情况，设置合适的超时参数。
四、BUG
1、操作系统卡死
比如系统已经无法ssh, 或者无法连接成功gbase服务。能连接但不能成功，一直卡住。
2、数据库BUG
现象和前面类似，内部BUG,这个需要联系厂商解决。
