GaussDB(DWS)等待视图之Hashjoin-nestloop

1. 业务场景

众所周知，GaussDB(DWS)中有3种常见的join方式：HashJon/MergeJoin/NestLoop

但在有一些场景中，等待视图中等待状态会显示为：HashJoin-nestloop，如下图所示。这种表示什么含义？

2. 基本原理

为了明白该状态的原因，首先思考如下场景：当业务侧两张大表join时，如果由于未做analyze或统计信息不准，导致build hash的一侧选择了大表，且该表在join列上重复值很多，会导致hashjoin时内存膨胀，当内存不足时，hashjon算子会下盘，但是由于join列上存在大量重复值，下盘文件无法有效分裂，此时，如果将整个文件都读取到内存中，会导致内存占用很高，出现内存过载，导致其他业务内存不足报错。

为了解决该场景，在向量化hashjoin时，当使用内表创建的hash表过大导致内存不足时，不再强制进行hashjoin，会通过内外表交换或执行nestloop使查询平稳进行，防止出现内存报错，此时，等待视图状态为“HashJoin-nestloop”

上述特性通过hashjoin_spill_strategy参数控制，默认为0，取值范围为0-6的整数，详情可以参考产品文档（8.1.2及以上版本），简单来讲：

取值为0或5，hashjoin时会先尝试内外表交换，如果仍然内存占用高，会选择nestloop；

取值为1或6，hashjoin时会先尝试内外标交换，如果仍然内存占用高，会强行执行hashjoin;

取值为2，hashjoin行为和原本的行为保持一致，即使内存不够，也会强制执行hashjoin

3. 业务影响

当等待视图出现Hashjoin-nestloop时，可能会导致原来内存占用高，单能执行成功的语句，在被转换成nestloop后，可能会短时间执行不出来。尤其是当数据量变化较大，统计信息差异较大时，容易出现执行计划非最优场景下的性能劣化。

4. 解决方法

如果出现上述HashJoin-nestloop时间长，导致业务超时的情况。可以将参数hashjoin_spill_strategy设置为2进行规避。不再进行内外表交换或执行nestloop，使业务行为与之前的行为保持一致。

在内存充裕的场景下，可以全局设置为2。