SQL性能优化-优化执行(更新中)

返回上一级

PBE

prepareStatement，将查询计划保存好，之后便可省去计划生成这一环节，其中保存的计划可以是存在参数的，后续执行时，只需要将参数绑定到计划上。

通常使用在OLTP场景，因为OLTP场景下的SQL，其计划生成环节在整个时间中的比例较大，且计划相对简单单一，因此将这部分提取出来，能获得很好的效果。

另外openGauss内存在全局计划缓存(GlobalPlanCache)的特性，这个特性并不会提升性能，主要是为了节省内存。

关于PBE的更多信息可看这篇 PBE协议

Bypass（OpFusion）

opfusion是openGauss独有的一个特性，可以理解成一个“简易执行器”，由会话级别参数enable_opfusion控制开启关闭，用来高性能的执行简单SQL。

在计划生成完成之后，进入Executor流程执行之前，会先对计划进行检查，若检查通过，则会进行拦截，转而由opfusion进行执行，因此也叫Bypass。
目前bypass仅支持索引扫描，以及几个简单算子的简单排列，通过相关GUC参数可额外支持Agg、Sort、分区表等部分功能，不支持JOIN。此部分可阅读代码 getFusionType() 进行了解。

观察一个SQL是否是走了bypass，可以通过explain，观察计划是否带[bypass]标签，也可通过相关参数了解检查未通过的原因。例如：

一些相关的GUC功能：
opfusion_debug_mode ：用于在explain中打印不满足bypass的原因。
enable_beta_fusion ：开启后可以额外支持AGG、SORT算子的部分功能。
sql_beta_feature ：一些beta特性，设置 PARTITION_OPFUSION 之后，可以额外支持分区表。

并行查询

并行查询即使在一个SQL内，使用多个线程并行完成。

通过参数query_dop控制，1表示单并行，即功能关闭，> 1表示并行度。目前暂无法动态的更改并行度，设置多少就是多少。

并行查询能够将数据分批后并行计算，可以成倍的提升一条sql的性能，当然也并非所有的SQL都可以并行，需要根据算子、计划实际分析看待。

显而易见，其使用的场景主要是复杂查询，对于简单的单点查询，并不会有什么效果。

向量化执行

传统的火山模型执行流程，每次流动的仅有一个元组，而向量化执行则为每次计算一批元组。

向量化执行主要用于对列存场景进行计算，因此其数据结构、计算单元的设计都是面向列存的。
而对于行存表场景以及行列存都存在的场景，目前的方案是实现了一对行列转换算子（VecToRow、RowToVec），将行存数据转换为向量化计算的Batch，进而使用向量化引擎进行计算。

在行存下，通过开启参数force。。。可以强行走向量化执行，但是其查询计划并非是代价递推生成的，而是先生成的行存计划，之后直接对行存计划进行直接改造，因此得到的向量化计划并不一定是比较好的。

向量化的计算会比逐行计算的模式快很多，但行列转换算子却会又带来额外的消耗，且目前消耗比较重。因此向量化执行并不一定能带来性能的提升，需要看这两部分的找补抵耗情况。