引言
最近几个月我们小组在做SQL拉数据相关的优化工作，主要涉及Trino、ES、Lucene三个模块的开发优化，具体优化包括列存-行转列读取、序列化协议优化、SQL字段Ord值（DocId - Ord - Term）批量预读三个核心点；第一阶段优化整体符合预期，优化后整体拉数据性能提升5倍+；本篇文档简单记录下优化中涉及到的两个小点，改进过程即是分析火焰图（主要是CPU占比分析），找出性能消耗可改进的点，然后思考进一步的解决方案，Coding落地，然后再打火焰图分析，其实一直是这样不断分析、不断改进的过程。
列存-行转列读取
核心点：每个字段在基于Ord排序并取值之后，如何保障字段之间原有的关联关系，比如原有的关系f1Ord2, f2Ord3, fnOrd3三者是对应的，因为Ord排序后的原因，导致三者之间获取值的顺序不再具有关联性，因此需要确保Ord排序之后，字段值之间该有的关联关系
方案一：针对每个字段，比如Field1，在基于Ord排序并获取值后，使用Map<DocId, Value>的结构存储；最终再基于DocId将字段之间的值给串联起来
方案二：从基础数据结构性质分析来看，Map结构在CPU与内存的使用上相比数组都要高一些；因此考虑用数组的方案存储Ord结果值数据并保证字段的关联关系
Ord顺序读取之排序
方案一：定义OrdCell类，每个对象持有Ord值与下标索引Index，排序时基于Ord进行排序；Java Arrays.sort方法排序，默认使用TimSort的排序算法；火焰图分析下来CPU占比约16%
方案二：着眼于进一步减少无效的排序规模，从减少OrdCell对象的排序规模来分析，我们的存储引擎是基于每64个Ord元素为一个Block的，因此我们仅需要对同一个Block内的元素进行排序即可，无需全局排序；具体做法是，对OrdCell对象先进行分组（0~63, 64~127, ...），然后对每一个Block内的OrdCell再进行排序（跨Block的无需排序）；整体优化下来，火焰图占比依然有13%
方案三：进一步考虑优化；因为Ord与下标Index均是Integer类型；因此考虑用long类型的高四位表示Ord值，低四位表示Index值；这样就把Timsort的排序算法转成DualPivotQuickSort的排序算法（基于原生类型排序，性能会更高一些）
排序消耗降低至7%
