doc-exports/docs/dws/dev/dws_04_0452.html

<a name="EN-US_TOPIC_0000001233681693"></a><a name="EN-US_TOPIC_0000001233681693"></a>

<h1 class="topictitle1">SQL Statement Rewriting Rules</h1>
<div id="body8662426"><div class="p" id="EN-US_TOPIC_0000001233681693__ad1704c533b3145c0b0e84527f84e4f3c">Based on the database SQL execution mechanism and a large number of practices, summarize finds that: using rules of a certain SQL statement, on the basis of the so that the correct test result, which can improve the SQL execution efficiency. You can comply with these rules to greatly improve service query efficiency.<ul id="EN-US_TOPIC_0000001233681693__u92ddb98e9fbe4be7a0c805df8c843d03"><li id="EN-US_TOPIC_0000001233681693__l4a5c8dddaf20464cb4c14cd32becf9de">Replacing <strong id="EN-US_TOPIC_0000001233681693__b8423527061175">UNION</strong> with <strong id="EN-US_TOPIC_0000001233681693__b8423527061172">UNION ALL</strong><p id="EN-US_TOPIC_0000001233681693__a582ad4b1a6b5494bac8f01c943148e25"><strong id="EN-US_TOPIC_0000001233681693__b842352706111859">UNION</strong> eliminates duplicate rows while merging two result sets but <strong id="EN-US_TOPIC_0000001233681693__b2035295036203222">UNION ALL</strong> merges the two result sets without deduplication. Therefore, replace <strong id="EN-US_TOPIC_0000001233681693__b486333212114938">UNION</strong> with <strong id="EN-US_TOPIC_0000001233681693__b1131587720114938">UNION ALL</strong> if you are sure that the two result sets do not contain duplicate rows based on the service logic.</p>
</li><li id="EN-US_TOPIC_0000001233681693__li883453014212"><strong id="EN-US_TOPIC_0000001233681693__b842352706153440">Adding NOT NULL to the join column</strong><p id="EN-US_TOPIC_0000001233681693__p517917521418">If there are many <strong id="EN-US_TOPIC_0000001233681693__b842352706162833">NULL</strong> values in the <strong id="EN-US_TOPIC_0000001233681693__b842352706162824">JOIN</strong> columns, you can add the filter criterion <strong id="EN-US_TOPIC_0000001233681693__b842352706162920">IS NOT NULL</strong> to filter data in advance to improve the <strong id="EN-US_TOPIC_0000001233681693__b842352706162952">JOIN</strong> efficiency.</p>
</li><li id="EN-US_TOPIC_0000001233681693__li7979122118211">Converting <strong id="EN-US_TOPIC_0000001233681693__b84235270616319">NOT IN</strong> to <strong id="EN-US_TOPIC_0000001233681693__b84235270616317">NOT EXISTS</strong><p id="EN-US_TOPIC_0000001233681693__p159801210213"><strong id="EN-US_TOPIC_0000001233681693__b842352706163238">nestloop anti join</strong> must be used to implement <strong id="EN-US_TOPIC_0000001233681693__b842352706163150">NOT IN</strong>, and <strong id="EN-US_TOPIC_0000001233681693__b84235270616343">Hash anti join</strong> is required for <strong id="EN-US_TOPIC_0000001233681693__b842352706163353">NOT EXISTS</strong>. If no <strong id="EN-US_TOPIC_0000001233681693__b22059043014">NULL</strong> value exists in the <strong id="EN-US_TOPIC_0000001233681693__b842352706163524">JOIN</strong> column, <strong id="EN-US_TOPIC_0000001233681693__b2006203659163541">NOT IN</strong> is equivalent to <strong id="EN-US_TOPIC_0000001233681693__b2114348645163541">NOT EXISTS</strong>. Therefore, if you are sure that no <strong id="EN-US_TOPIC_0000001233681693__b84235270617307">NULL</strong> value exists, you can convert <strong id="EN-US_TOPIC_0000001233681693__b842352706163820">NOT IN</strong> to <strong id="EN-US_TOPIC_0000001233681693__b842352706163823">NOT EXISTS</strong> to generate <strong id="EN-US_TOPIC_0000001233681693__b842352706163919">hash joins</strong> and to improve the query performance.</p>
<p id="EN-US_TOPIC_0000001233681693__p1698112211928">As shown in the following figure, the <strong id="EN-US_TOPIC_0000001233681693__b842352706155228">t2.d2</strong> column does not contain null values (it is set to <strong id="EN-US_TOPIC_0000001233681693__b842352706155115">NOT NULL</strong>) and <strong id="EN-US_TOPIC_0000001233681693__b1930992475154956">NOT EXISTS</strong> is used for the query.</p>
<div class="codecoloring" codetype="Sql" id="EN-US_TOPIC_0000001233681693__screen19813214215"><div class="highlight"><table class="highlighttable"><tr><td class="linenos"><div class="linenodiv"><pre><span class="normal">1</span></pre></div></td><td class="code"><div><pre><span></span><span class="k">SELECT</span><span class="w"> </span><span class="o">*</span><span class="w"> </span><span class="k">FROM</span><span class="w"> </span><span class="n">t1</span><span class="w"> </span><span class="k">WHERE</span><span class="w">  </span><span class="k">NOT</span><span class="w"> </span><span class="k">EXISTS</span><span class="w"> </span><span class="p">(</span><span class="k">SELECT</span><span class="w"> </span><span class="o">*</span><span class="w"> </span><span class="k">FROM</span><span class="w"> </span><span class="n">t2</span><span class="w"> </span><span class="k">WHERE</span><span class="w"> </span><span class="n">t1</span><span class="p">.</span><span class="n">c1</span><span class="o">=</span><span class="n">t2</span><span class="p">.</span><span class="n">d2</span><span class="p">);</span>
</pre></div></td></tr></table></div>

</div>
<p id="EN-US_TOPIC_0000001233681693__p29821621223">The generated execution plan is as follows:</p>
<div class="fignone" id="EN-US_TOPIC_0000001233681693__fig69829215214"><span class="figcap"><b>Figure 1 </b><strong id="EN-US_TOPIC_0000001233681693__b842352706164111">NOT EXISTS</strong> execution plan</span><p id="EN-US_TOPIC_0000001233681693__p656888105711"><span><img id="EN-US_TOPIC_0000001233681693__image767820414588" src="figure/en-us_image_0000001233883423.png"></span></p>
</div>
</li><li id="EN-US_TOPIC_0000001233681693__lbe25437171eb40049fdfa2738da25290">Use <strong id="EN-US_TOPIC_0000001233681693__a20b0e4587ee14f5aaf7ccb814a249c03">hashagg</strong>.<p id="EN-US_TOPIC_0000001233681693__a5e5520430c64442a8c4d585a8718f309">If a plan involving groupAgg and SORT operations generated by the <strong id="EN-US_TOPIC_0000001233681693__b842352706163549">GROUP BY</strong> statement is poor in performance, you can set <strong id="EN-US_TOPIC_0000001233681693__b842352706163616">work_mem</strong> to a larger value to generate a <strong id="EN-US_TOPIC_0000001233681693__b842352706163629">hashagg</strong> plan, which does not require sorting and improves the performance.</p>
</li><li id="EN-US_TOPIC_0000001233681693__l075b3843b1094fd8af9493cfea51af37">Replace functions with <strong id="EN-US_TOPIC_0000001233681693__a9718845774e14f59956845762f685ec5">CASE</strong> statements<p id="EN-US_TOPIC_0000001233681693__a2d04428bf92e4e77817352d7d05c9903">The <span id="EN-US_TOPIC_0000001233681693__text197658622">GaussDB(DWS)</span> performance greatly deteriorates if a large number of functions are called. In this case, you can modify the pushdown functions to <strong id="EN-US_TOPIC_0000001233681693__en-us_topic_0058968293_b2013463445111552">CASE</strong> statements.</p>
</li><li id="EN-US_TOPIC_0000001233681693__l2e42abdafe464591a46402c5016e31f6"><strong id="EN-US_TOPIC_0000001233681693__b842352706174846">Do not use functions or expressions for indexes.</strong><p id="EN-US_TOPIC_0000001233681693__a3d88dfc1cc624ddaa6170498baeadbe7">Using functions or expressions for indexes stops indexing. Instead, it enables scanning on the full table.</p>
</li><li id="EN-US_TOPIC_0000001233681693__l1aa44c0017d544769c1263820a4ab1af">Do not use <strong id="EN-US_TOPIC_0000001233681693__b842352706172121">!=</strong> or <strong id="EN-US_TOPIC_0000001233681693__b842352706172125">&lt;&gt;</strong> operators, <strong id="EN-US_TOPIC_0000001233681693__b842352706112511">NULL</strong>, <strong id="EN-US_TOPIC_0000001233681693__b842352706112526">OR</strong>, or implicit parameter conversion in <strong id="EN-US_TOPIC_0000001233681693__b842352706112635">WHERE</strong> clauses.</li><li id="EN-US_TOPIC_0000001233681693__l2e97f2e667fc49df960105f3fc7af32d"><strong id="EN-US_TOPIC_0000001233681693__b84235270617564">Split complex SQL statements.</strong><p id="EN-US_TOPIC_0000001233681693__ad47b8edd10434caf84f53a4552b3b1eb">You can split an SQL statement into several ones and save the execution result to a temporary table if the SQL statement is too complex to be tuned using the solutions above, including but not limited to the following scenarios:</p>
<ul id="EN-US_TOPIC_0000001233681693__uec24d743a7554b9590302dee655bfff7"><li id="EN-US_TOPIC_0000001233681693__lc9e7a993930645f6b3410bfdf7869245">The same subquery is involved in multiple SQL statements of a task and the subquery contains large amounts of data.</li><li id="EN-US_TOPIC_0000001233681693__l873b289f78c94914a023f220e6ba9c5a">Incorrect <strong id="EN-US_TOPIC_0000001233681693__b84235270616325">Plan cost</strong> causes a small hash bucket of subquery. For example, the actual number of rows is 10 million, but only 1000 rows are in hash bucket.</li><li id="EN-US_TOPIC_0000001233681693__l34bd6efb417046ec996aebb6459d9364">Functions such as <strong id="EN-US_TOPIC_0000001233681693__b842352706115921">substr</strong> and <strong id="EN-US_TOPIC_0000001233681693__b842352706115925">to_number</strong> cause incorrect measures for subqueries containing large amounts of data.</li><li id="EN-US_TOPIC_0000001233681693__l5ffc00e243a64f3f90aad7a3443905e7"><strong id="EN-US_TOPIC_0000001233681693__b842352706141044">BROADCAST</strong> subqueries are performed on large tables in multi-DN environment.</li></ul>
</li></ul>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="dws_04_0430.html">SQL Optimization Guide</a></div>
</div>
</div>