本文针对GBase 8a 在最简单的精确查询场景下，已知的优化手段进行汇总，包括Hash分布，global hash索引，行存列，并行物化，预排序等。后续如有更多的方法会逐渐补充。

精确查询
指等值的查询，比如查询2021年8月8日的天表，主叫号码为13912345678的通话记录。

select * from MyTable_20210808 where calling_number=13912345678;

优化分析
这类查询分成2个阶段分析，其中

定位阶段负责根据查询列，找到符合要求的数据行；
根据数据行，读取【整行数据】，并返回结果。

定位阶段
负责根据指定条件，找到哪些数据行，符合条件要求。一般都是通过索引的方式来提高性能。

GBase 8a是通过hash索引来优化这部分。该索引适合重复度低的数据列，比如电话号码，身份证号等。而对于重复度高的，比如民族，地区等，则【可能】性能降低。 一般可以评估，低于千分之1的，可以认为重复度低。具体的可以实际测试为准。

返回结果阶段
对于传统的行存数据库，只要定位到行，就可以快速的读取到整行数据；而对于列存数据库，则需要考虑，如何减少拼凑不同列到一行的问题。列越多，拼凑的代价越大。在GBase 8a里，这部分叫【物化】（Materialization）。

行存列
GBase 可以通过行存列方式，用空间换时间，提高这个阶段的效率

并行物化
另外，在少量查询，非高并发场景，也就是磁盘资源不是极端争抢的场景下，可以考虑并行物化参数的影响，当返回结果集少，且且资源争抢不高时，可以适当调整该参数，做并行物化。

预排序
如果数据是按照查询列排序的，那么其命中的数据，将是连续的，如此磁盘消耗将会降低到最小，极大提高性能。 但是排序是需要时间的，跨度越大，虽然性能越好，但排序时间也越长。另外，同一个表，也最多有1个排序列。

在某些场景，这也是一个【可选项】，特别是针对【历史数据】，入库一次，会查很多次。

Hash分布列选择
是否对查询列做hash分布，取决于查询并发数。备注：hash分布后，相同条件的数据将落在同一节点上。

低并发
只有少量查询，【不建议】做Hash分布。让更多的节点参与计算，可以提高查询性能。

高并发
最常见的是电信行业对【公众】提供【详单查询】。每个人虽然每月只有几十，几百条数据，但同一时间，可能有几百，几千人同时查询，月初某个时间段可能会更多。此时建议做Hash分布。

通过Hash分布，同一个条件的查询，一个节点即可完成，多个查询间，有较大概率落在不同的节点上，从【整体上】，降低了资源争抢，提高了整体能支撑的并行查询数量，同时，也非常有利于扩容时的资源评估