从整体上看，GBase 8a数据库集群提升性能，包括查询，加载，更新等等，都归类到三类方法，按照重要程度如下：
1、优化业务SQL
2、优化数据库参数
3、增加更多的硬件
本文针对如上三类，根据项目经验，针对可能的优化点做出分析。
目录导航
优化业务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。
比如多个采集端口，生成各自的数据文件，在加载前可以合并成一个文件或尽量少的文件。这样在加载时，不仅仅数据源性能好，也减少了集群和数据源的通讯次数，提升了加载性能。
业务并发控制
需要开发和设计人员，控制并发。比如连接池大小，定时任务周期，任务先后顺序。
包括并发加载、并发查询、并发导出、并发后台处理。大型任务尽量在非重要时间（比如凌晨）进行。
优化数据库参数
通过调整数据库参数，提高或稳定业务性能。
并发控制
选择合适的并发数，不是高并发，一定带来高性能。
如硬件资源有限，比如特别是CPU,磁盘，过高的并发或导致内部竞争，CPU的表现是大量的Sys，磁盘的表现就是Busy100%但吞吐量很低。
整体并发参数
可以通过数据库的资源管控，限制同时运行的SQL数量，后续SQL是排队状态。
单个SQL并发参数
主要是内部线程并行度参数，以多少个内部现场处理一个SQL。高并发下可以考虑降低并行度，以降低资源竞争。
主要涉及和degree有关的参数
详情可以参考数据库参数部分。
内存控制
在内存有限的前提下，。大并发必然会导致内存不足，在保证有限并发可用时，必须要调增数据库的内存参数，避免内存不足导致报错或者大量的SWAP导致性能急剧下降。
内存参数请参考 GBase 8a集群常见内存配置参数
增加更多的硬件
这个不用多说了，更好的硬件必然带来更高的性能，支持更多的并发。
建议：对重要业务，使用频率高的业务，通过表空间、虚拟集群等方案，将数据保存到更高性能的服务器或者硬盘上。
虚拟集群
通过虚拟机群的物理隔离，可以按照业务重要性，实时性要求，划分多个集群，来保证最重要的业务获得最高的硬件支持。
表空间
通过表空间，将重要的表保存到性能更高的磁盘上，比如ssd, flash卡等。
多实例
特别针对超多CPU，比如国产ARM平台服务器，超大内存，超过512GB，可以通过多实例部署的方案，提高硬件资源的利用率，包括numa绑定提高CPU和内存的高效利用。