forked from docs/doc-exports
Lu, Huayi
a24ca60074
Reviewed-by: Hasko, Vladimir <vladimir.hasko@t-systems.com> Co-authored-by: Lu, Huayi <luhuayi@huawei.com> Co-committed-by: Lu, Huayi <luhuayi@huawei.com>
19 lines
2.7 KiB
HTML
19 lines
2.7 KiB
HTML
<a name="EN-US_TOPIC_0000001145494815"></a><a name="EN-US_TOPIC_0000001145494815"></a>
|
|
|
|
<h1 class="topictitle1">Case: Adjusting the Distribution Key</h1>
|
|
<div id="body8662426"><div class="section" id="EN-US_TOPIC_0000001145494815__s402f3c77116945dab099df1af9d01369"><h4 class="sectiontitle">Symptom</h4><p id="EN-US_TOPIC_0000001145494815__ac32f10d57e7f48dfb1c3156b3fce6302">During a site test, the information is displayed after <strong id="EN-US_TOPIC_0000001145494815__b842352706173340">EXPLAIN ANALYZE</strong> is executed:</p>
|
|
<p id="EN-US_TOPIC_0000001145494815__p1260216181169"><span><img id="EN-US_TOPIC_0000001145494815__image1740542341615" src="figure/en-us_image_0000001099135194.png"></span></p>
|
|
<p class="litext" id="EN-US_TOPIC_0000001145494815__af1a3185d988244f3ace4718cb2b36358">According to the execution information, HashJoin becomes the performance bottleneck of the whole plan. Based on the execution time of HashJoin <strong id="EN-US_TOPIC_0000001145494815__b842352706173223">[2657.406, 93339.924]</strong>, it can be seen that severe skew occurs on different DNs during the HashJoin operation.</p>
|
|
<p class="litext" id="EN-US_TOPIC_0000001145494815__aa5ab8bab8dcd4e5f80f0ecf82e79d0c3">In the memory information (as shown in the following figure), it can be seen that the data skew occurs in the memory usage of each node.</p>
|
|
<p id="EN-US_TOPIC_0000001145494815__p171404553169"><span><img id="EN-US_TOPIC_0000001145494815__image17735621615" src="figure/en-us_image_0000001145895187.png"></span></p>
|
|
</div>
|
|
<div class="section" id="EN-US_TOPIC_0000001145494815__sbc08fd969b9a4641b8645f621bfd75c3"><h4 class="sectiontitle">Optimization Analysis</h4><p class="litext" id="EN-US_TOPIC_0000001145494815__ad8b01f28b03748308497b50ab841ddda">The preceding two symptoms indicate that this SQL statement has serious computing skew. The further lower-layer analysis on the HashJoin operator shows that serious computing skew <strong id="EN-US_TOPIC_0000001145494815__b842352706173230">[38.885,2940.983]</strong> occurs in <strong id="EN-US_TOPIC_0000001145494815__b842352706173236">Seq Scan on s_riskrate_setting</strong>. Based on the description of the Scan, we can infer that the performance problems of this plan lie in data skew occurred in the <strong id="EN-US_TOPIC_0000001145494815__b842352706173244">s_riskrate_setting</strong> table. Later, it is proved that serious data skew occurred in the <strong id="EN-US_TOPIC_0000001145494815__b842352706173254">s_riskrate_setting</strong> table. After performance optimization, the execution time is reduced from 94s to 50s.</p>
|
|
</div>
|
|
</div>
|
|
<div>
|
|
<div class="familylinks">
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="dws_04_0474.html">Optimization Cases</a></div>
|
|
</div>
|
|
</div>
|
|
|