GBASE南大通用技术分享：GBase 8a数据库集群性能优化方法之—优化业务SQL

南大通用GBase 8a数据库集群提升性能，主要包括查询，加载，更新等等，都归类到三类方法，按照重要程度如下：

1）、优化业务SQL
2）、优化数据库参数
3）、增加更多的硬件

本文针对如上三类，根据项目经验，针对可能的优化点做出分析。

1、优化业务SQL
这类优化，包括业务SQL自身，表结构，数据等方面。

表结构

目前涉及到的主要是hash分布表的分布列选择，以及何时使用复制表的情况。

Hash分布表

选择好的Hash分布表，可以避免在做group, join时数据在各个计算节点间的一次额外的数据传输。

如果需要group或join的数据都在本地，则直接在本地做运算，只需要将计算结果发送到汇总节点即可。如果Hash列不正确，则需要做一次动态Hash：创建临时表，将每个计算节点需要计算的数据，根据需要分组的列，做一次数据重分布，然后在各个节点的临时表做计算。

如果数据量很大，则这个重分布的过程将额外花费一次磁盘读取、网络传输和接收方的磁盘写入。

建议的Hash列选择：
1、group 或者 join的列
2、该列唯一值很多。不能是大量的重复值

如果你的group、join列多个条件，那就选择最重要，使用频率最高的业务，唯一值最多的列做Hash分布列，常见的有IMSI，MSISDN，callingnumber, IDNumber等。

特殊情况：如果你有多个业务同样重要，那么可以考虑做多个表，分别用不同的Hash列对应不同的业务。

提示：GBase 8a V9版本开始支持多列Hash, 在某些场景下可以缓解数据单列Hash分布倾斜现象。

复制表

如果数据量不是很大，比如100万以内，或者数据量虽然较大，但变动很少。用途经常是作为基础表、维度表使用，那么建议用复制表。

复制表在每个计算节点有完整的一份，在与其它表做join时，无需在进行重分布。

另外如果是用于频繁查询的小表，数据量少但并发很高，也可以用复制表，加上连接的负载均衡，可以最大化提高并发数量。比如最终展示的结果报表。

Hash 索引

如果在大数量里，比如单个数据节点超过1000万，有明确的精确查询，其重复度低，结果集不多，可以建立Global Hash索引。

该索引只对精确查询有效，对范围查询，模糊查询等都无效。

行存列

如果业务最终要返回大量的列，比如查询详单，可以通过行存列grouped的方式，降低这类查询消耗的磁盘IO，提升这类查询性能。

全文索引

如果有频繁的like操作，且匹配的数据长度大于3个字符，可以考虑用全文索引。如果匹配字符太少，比如 like ‘%138%’,就得根据测试评估了。

SQL写法

这类优化主要方向是，规避列存数据库的劣势，发挥其优势。以及一些实现相同功能的更高效的写法等方面。

减少不必要的数据使用

1、避免或减少select *

不要完全依赖数据库的优化，在SQL写法上，尽量避免select *的写法。特别是最终只使用有限的几个列。

去掉不必要的全排序order

同样不能完全依赖数据库的优化，特别是在一些嵌套的内部查询，全排序与否完全不影响最终结果。

请区分和最外层返回客户端结果集的业务区别，这个排序还是需要的。在业务允许的情况下，建议加上limit。

避免笛卡尔

join的顺序或关联字段，尽量保证结果集不要无限扩大导致笛卡尔。

比如两个表的性别做join,除非特殊业务，否则真的没有什么意义。

选择合适的group和join列顺序

如果group或join的有多个列，且不是hash分布表或者不包含hash分布列，那么就将重复值最低的列放在最前面。

比如 group by gender,phonenumber 应改写成 group by phonenumber, gender,因为手机号的重复值更低。

业务调度

批量加载处理

在允许的时间实时性要求范围内，尽量减少加载小文件的数量和次数。加载文件大小，考虑网速，磁盘性能，建议不低于1-10GB。

比如多个采集端口，生成各自的数据文件，在加载前可以合并成一个文件或尽量少的文件。这样在加载时，不仅仅数据源性能好，也减少了集群和数据源的通讯次数，提升了加载性能。

业务并发控制

需要开发和设计人员，控制并发。比如连接池大小，定时任务周期，任务先后顺序。

包括并发加载、并发查询、并发导出、并发后台处理。大型任务尽量在非重要时间（比如凌晨）进行。