本文分享自華爲雲社區《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。