数仓的等待视图中,为什么会有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。

 

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

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章