数仓的等待视图中，为什么会有 Hashjoin-nestloop

本文分享自华为云社区《GaussDB(DWS)等待视图之Hashjoin-nestloop》，作者：Arrow0lf。

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。

点击关注，第一时间了解华为云新鲜技术~