GaussDB(DWS)性能調(diào)優(yōu)系列實戰(zhàn)篇五：十八般武藝之路徑干預(yù)

一、cost模型選擇

顧名思義，cost_param是控制cost相關(guān)的一個參數(shù)。在了解cost_param之前，先回顧一下選擇率的概念，GaussDB優(yōu)化器中的選擇率是指，當(dāng)一個表有一個過濾或關(guān)聯(lián)條件時，通過該條件能被選中的行數(shù)占總行數(shù)的比例，是介于0~1之間的一個實數(shù)。選擇率在優(yōu)化器中是一個重要的概念，主要應(yīng)用于行數(shù)和distinct值的估算，行數(shù)和distinct值是計劃生成中的基本要素。

首先，我們來看帶有過濾條件的基表行數(shù)如何估算。如果一個表只有一個過濾條件，那么以選擇率乘以表的行數(shù)，即可得到過濾完的行數(shù)；如果有多個過濾條件，那么就需要算出一個綜合的選擇率，如何計算？方式有二：一是通過多列統(tǒng)計信息直接計算，二是通過組合單列的選擇率。那么組合的方式就由參數(shù)cost_param決定了，具體地，

舉一個例子，TPC-H 1x的part表，過濾條件是：p_brand = 'Brand#45' and p_container = 'WRAP CASE'，查看不同cost_param下的過濾后行數(shù)。

（1）cost_param=0

（2）cost_param=2

從估算出的行數(shù)（E-rows）和實際的行數(shù)（A-rows）對比可以看出，cost_param=0的不相關(guān)模型適合part表的p_brand和p_container列。

其次，Join的行數(shù)怎么估算的呢？原理跟過濾條件的行數(shù)估算是類似的，如果沒有多列統(tǒng)計信息可以使用，則也需要單獨計算每個條件的選擇率，然后計算出綜合選擇率，得出行數(shù)。例如 TPC-H 1x lineitem和orders關(guān)聯(lián)，關(guān)聯(lián)條件是：l_orderkey = o_orderkey and o_custkey = l_suppkey，不同cost_param的執(zhí)行情況如下：

（1）cost_param=0

（2）cost_param=2

此例中，Join的列之間也適合完全相關(guān)模型，這與l_orderkey和l_suppkey的分布是吻合的。

由于TPC-H的模型接近完全不相關(guān)模型，因此cost_param=0模型可以較好的描述場景，實際應(yīng)用中，用戶可以根據(jù)具體業(yè)務(wù)場景來調(diào)整模型，行數(shù)估算的準(zhǔn)確性是計劃生成的重要保證，在調(diào)優(yōu)中檢查估算的最直接的地方。GaussDB會在后續(xù)版本中新增更多的模型供業(yè)務(wù)需求選擇。

二、Scan方式的選擇

GaussDB中掃描方式主要分順序掃描和索引掃描，每種掃描方式都對應(yīng)若干掃描算子，順序掃描在行列存中對應(yīng)的掃描算子分別是Seq Scan和CStore Scan算子（下面我們討論中不加區(qū)分）。這些掃描算子大部分都可以通過開關(guān)來進行調(diào)控，例如Seq Scan，如果設(shè)置enable_seqscan=off，則表示不會優(yōu)先選擇Seq Scan，而不是一定不會選。掃描方式的選擇，很大程度上決定了獲取基表數(shù)據(jù)的路徑。我們以如下的例子來說明：

select?l_orderkey,?o_custkey?from?lineitem,?orders?where?l_orderkey?=?o_orderkey;

lineitem分布鍵是l_orderkey，并且在l_orderkey上有index，orders分布鍵是o_orderkey。默認(rèn)情況下，Scan的方式如下：

兩個表都是順序掃描的路徑，關(guān)聯(lián)方式選擇了Hash Join。如果把Seq Scan關(guān)掉（enable_seqscan=off）,計劃如下：

lineitem的掃描變成了Index Only Scan（因為l_orderkey的類型是int），而在orders表上仍然選擇Seq Scan（因為沒有其他路徑），同時關(guān)聯(lián)方式也變?yōu)榱薔est Loop，因為Hash Join需要全表掃描數(shù)據(jù)（lineitem的Seq Scan已經(jīng)被關(guān)掉了）。優(yōu)化器的選擇方式我們從代價（E-costs）一欄中也可以看出。再把Index Only Scan關(guān)掉，看看計劃如何變化：

掃描路徑都變?yōu)榱薙eq Scan，而且Seq Scan的代價都很大。此時既然都走了Seq Scan，為什么不選Hash Join呢，把Nest Loop關(guān)掉，看看Hash Join計劃的代價：

從代價上看出Hash Join的總代價比Nest Loop的小，但優(yōu)化器沒有選擇Hash Join，這是因為優(yōu)化器比較路徑代價時，會比較Startup和Total代價，即啟動代價和總代價，綜合考慮，E-costs欄中顯示的是總代價。把explain_perf_mode設(shè)置為normal，查看原Nest Loop的啟動代價：

紅框中的兩個cost，分別是啟動代價和總代價，在看Hash Join的cost，明顯Hash Join的啟動代價比Nest Loop的大很多（啟動代價代表了輸出第一條數(shù)據(jù)的代價），優(yōu)化器在比較路徑時，綜合了這兩個代價，最終推薦了Nest Loop的路徑。

從上面的例子可以看出，掃描路徑的調(diào)控，可以改變路徑生成，合理的搭配是生成最優(yōu)計劃的前提，默認(rèn)情況下，GaussDB優(yōu)化器可以根據(jù)現(xiàn)有的路徑選擇（如上面的lineitem有兩條掃描路徑，orders只有一條掃描路徑），最后確定出最優(yōu)的一條。兩條路徑代價比較時，總代價不是唯一要素，但總代價越小，一般也會越容易被選中。

三、關(guān)聯(lián)方式的選擇

GaussDB優(yōu)化器中表關(guān)聯(lián)的主要方式有：Nest Loop，Hash Join和Merge Join，分別可以通過enable_nestloop、enable_hashjoin、enable_mergejoin進行控制，這種控制也不是絕對的，可以理解為是否優(yōu)先選擇。大部分場景下，三種路徑的代價關(guān)系：Hash Join < Merge Join < Nest Loop。我們以一個簡單的關(guān)聯(lián)示例說明，store_returns和store_sales是TPC-DS 1x中兩個表，SQL如下：

select?count(*)?from?store_returns,?store_sales?where?sr_customer_sk?=?ss_customer_sk;

默認(rèn)情況下，優(yōu)化器推薦Hash Join路徑，計劃如下：

如果把Hash Join關(guān)掉，則優(yōu)化器選擇了Merge Join路徑：

如果再把Merge Join路徑關(guān)掉，可能就會選擇Nest Loop路徑。關(guān)聯(lián)方式的控制開關(guān)一般用于調(diào)優(yōu)或規(guī)避問題，但具體是否能夠起作用要看具體的語句，除了當(dāng)前關(guān)聯(lián)方式，還有沒有其他方式。實際場景中，一個語句中關(guān)聯(lián)的算子較多，一般很難用參數(shù)enable_hashjoin或enable_nestloop或enable_mergejoin來控制某兩個表的Join方式，GaussDB中更細(xì)致的語句級別的調(diào)優(yōu)手段是Plan Hint，感興趣的讀者可以參考產(chǎn)品手冊。

四、Stream方式的選擇

Stream算子是GaussDB分布式執(zhí)行的關(guān)鍵算子之一，主要起到網(wǎng)絡(luò)傳輸?shù)淖饔茫乓榻B可以參考：GaussDB(DWS)性能調(diào)優(yōu)系列實戰(zhàn)篇一：十八般武藝之總體調(diào)優(yōu)策略。Stream算子由參數(shù)enable_stream_operator控制，如果關(guān)掉Stream算子，則可能導(dǎo)致生成不下推的計劃，例如：

因為lineitem表關(guān)聯(lián)的鍵l_partkey不是lineitem的分布鍵，需要添加Stream算子，但Stream功能被禁，于是只能生成不下推計劃。

GaussDB計劃中常見的主要Stream算子包括Redistribute、Broadcast和Gather。Gather一般是分布式計劃中，CN用于收集DN的數(shù)據(jù)進行最后的處理，除非最后收集的行數(shù)非常多，這個算子涉及性能問題一般較少。Redistribute和Broadcast一是對“互補”的算子，前者用于重分布，后者用于廣播，生成計劃時，優(yōu)化器會根據(jù)代價大小來選擇。當(dāng)Join Key沒有包含表的分布鍵的時候，一般會添加Redistribute路徑，能選擇Redistribute路徑理論上也可選擇Broadcast路徑，最終選擇哪條路徑要看優(yōu)化器估算的代價是多少。這兩個算子可以通過參數(shù)enable_redistribute和enable_broadcast進行控制。

在SMP開啟的情況下，當(dāng)并行度（dop）大于1時，一般還會有Local Redistribute、Split Redistribute、Local Broadcast和Split Broadcast；當(dāng)傾斜優(yōu)化開啟時，還有PART REDISTRIBUTE PART ROUNDROBIN、PART_REDISTRIBUTE_PART_BROADCAST、PART_REDISTERIBUTE_PART_LOCAL等等，這些也是Stream算子，主要就是重分布、廣播、RoundRobin的一些擴展形式，這里我們不一一介紹了，感興趣的讀者可以參考GaussDB DWS 產(chǎn)品手冊。

我們考慮兩個表的簡單關(guān)聯(lián)，store_sales和sr_tbl，它們的分布鍵分別是ss_item_sk 和sr_returned_date_sk，Join 條件是store_sales.ss_customer_sk =sr_tbl. sr_customer_sk，執(zhí)行結(jié)果如下：

由于兩個表的分布鍵都不是Join Key，因此走Hash Join路徑的話需要有一個表做Broadcast或者兩個表都做Redistribute，但是store_sales表比較大（E-rows顯示28.7億行），而sr_tbl表行數(shù)估算比較少（E-rows顯示100行），優(yōu)化器認(rèn)為適合做Broadcast。于是最終選擇了一邊Broadcast的計劃。

對于這個計劃，由于sr_tbl表統(tǒng)計信息不準(zhǔn)確（如果是中間結(jié)果集，則表示中間結(jié)果集估算不準(zhǔn)），一種調(diào)優(yōu)的方法是，將sr_tbl的表統(tǒng)計信息重新收集準(zhǔn)確一些（如果sr_tbl是中間結(jié)果集，則無法收集），另一種方法是讓sr_tbl走Redistribute路徑，而后者我們又有兩種方式來實現(xiàn)，一是用Plan Hint，即在生成計劃時，告訴優(yōu)化器走Redistribute路徑，二是把Broadcast關(guān)掉。禁用Broadcast后，執(zhí)行計劃如下：

本列中，開啟了SMP自適應(yīng)，即優(yōu)化器會根據(jù)系統(tǒng)資源和當(dāng)前Active SQL數(shù)量來自行決定并行度（dop），如果Redistribute和Broadcast選擇不當(dāng)，則可能導(dǎo)致

（1）Broadcast計劃會出現(xiàn)下盤

（2）兩個計劃的并行度不一樣，最終執(zhí)行時間可能會差異比較大。

對于Stream方式的控制，一般的調(diào)優(yōu)方式有Plan Hint、GUC參數(shù)、改善統(tǒng)計信息或估算信息。Plan Hint的詳細(xì)介紹可以參考產(chǎn)品手冊或者：GaussDB(DWS)性能調(diào)優(yōu)系列實戰(zhàn)篇六：十八般武藝Plan hint運用。

五、結(jié)束語

本文介紹的cost_param屬于cost底層參數(shù)，建議對數(shù)據(jù)特征和使用場景比較熟悉的DBA慎重使用。Scan、Join、Stream調(diào)控的基本依據(jù)也是代價，代價一般體現(xiàn)在執(zhí)行耗時上，調(diào)優(yōu)時可從Performance中識別出性能的瓶頸點，分析選擇的算子是否與代價匹配。另外，除了本文介紹的Session級別的控制參數(shù)外，還有基表、中間結(jié)果的行數(shù)，也可以通過Plan Hint進行語句級別的調(diào)控，感興趣讀者可通過GaussDB DWS產(chǎn)品文檔進一步了解。

EI企業(yè)智能 數(shù)據(jù)倉庫服務(wù) GaussDB(DWS) HUAWEI CONNECT Gauss AP SQL

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。