Shanghai Tengke Education Damengデータベーストレーニング乾物共有DamengSQL最適化-基本記事(3)

共有に関する前の2つの問題では、単一テーブルおよび複数テーブルのクエリで使用されるSQL演算子を紹介しました。今回は、フィルタリングとグループ化の並べ替えに使用される演算子について説明します。

 

フィルター条件:SLCT

このタイプの演算子は比較的単純で、結果セットをフィルタリングします。注意が必要なのは、演算子の説明情報です。説明情報から、下位レベルの操作に使用できるフィルター条件を確認できます。これらの条件は、多くの場合、最適化の方向性のソースになります。 。

 

 

注意が必要なのは、SLCT(exp_cast(T2.ID)> 5 AND exp11 <= 0)の説明部分です。ここで、括弧内の内容はID> 5をEXP_CAST(T2.ID)> 5としてマークし、ID NOT LIKE '%c % 'はEXP11 <= 0としてマークされます。EXP_CAST(T2.ID)> 5によって提供される情報は、列IDを数値5と比較すると、列タイプが変換されることを示しています。つまり、ID列にインデックスがある場合でも、範囲スキャンができない場合があります。 、インデックス範囲スキャンの入力要件はインデックス列のタイプと同じなので、確認してみましょう

 

実際、インデックスがある場合(t2(id)にindexi_index3を作成)、単一列の同等のクエリはクエリにインデックスを使用しません。これは一般的な原則にすぎません。さまざまなタイプのデータを比較する場合、最初に1つが選択されます。タイプを比較してから、比較方法を決定します。たとえば、この例では、ID(VARCHAR)= 5(INT)を比較すると、サーバーは比較のためにタイプをINTに変換することを優先的に選択するため、ID列をタイプ変換して、インデックスを使用できないようにする必要があります(変換されたデータを格納するインデックスはありません)。 )。この場合、インデックス列の比較オブジェクトをインデックス列と同じ形式に変換する必要があります

 

 

 

別の条件、ID NOT LIKE '%c%'はEXP11 <= 0に変換され、実際にはNOT LIKEがINSTR(ID、 'c')<= 0に変換されます。この原則は、ここでは繰り返されません。それがしたことは

SLCTの説明項目ごとに、対応する条件が元のSQLにあり、最適化の可能性があるかどうかを確認できます。

 

分组:HAGR,SAGR

これらのタイプの演算子はすべて、フェッチされたデータに対して何らかの処理を行うか、マージまたはソートし、場合によってはマージとソートが相互運用可能です。まず、これらの演算子の基本的な状況を見てみましょう。GROUPステートメントがあり、これら2つのうちの1つが表示される可能性があります

 

SQL> create table t4(id int、id1varchar);

SQL> t4 select level、levelfrom dual connect by level <10000に挿入します。

SQL>コミット;

 

 

HAGRは、最適化条件なしでステートメントをグループ化するための最も基本的なグループ化方法であるHASH AGR操作であり、一般にこのようにグループ化されます。グループ化の原則はHASH INNER JOINの方法と同様であり、元のテーブルデータが取り出され、各計算がFOLDされます。同じで、後続の条件を満たすFOLDがグループにマージされていることがわかります(ベーステーブルのデータが非常に大きい場合、HAGRの計算量を無視できないことを見つけるのは難しくありません。特定の条件が満たされた場合、orderedを使用できます。セックスウォーキングSAGRオペレーター

 

SQL>インデックスの作成または置換i_test4ont4(id、id1);

 

 

 

SAGR演算子がここに表示され、下位層の出力がグループ化列でソートされ、下位層がSSCN I_TEST4であり、I_TEST4が(ID、ID1)複合インデックスであり、IDに従って順序付けられ、SAGR条件を満たすことを示します。

 

SAGR、SORTED AGR操作、HASH AGRとは異なり、下位層のデータが順序付けられているため、同じグループのデータを順番に取り出すことができ、多くの計算を節約できます。

 

並べ替え:並べ替え:

SORTは、ソート操作に使用される演算子であり、以下の実験を行うことができます。

 

 

ご覧のとおり、ここにはSORT演算子はありません。前述のように、インデックスI_TESTはすでにID順に並べられているため、下位SSCNで並べ替えタスクが完了しています。テストする列を変更した場合。

 

SQL> select id、id1 from t4order by id1 desc;

 

 

 

id1列をソートする場合は、SSCNの後にid1のSORTを実行する必要があります。これは、データベースにとって大きなオーバーヘッドです。したがって、実際の使用では、インデックスの順序を使用して並べ替え操作を完了する方法も見つけることができます。

 

これで、DamengSQL最適化の基本の概要は終わりです。フォローアップ共有では、実行計画ビューとインデックス作成の知識も紹介しますので、ご期待ください。

 

[乾物共有] DamengSQL最適化-基本記事

【乾物シェアリング】ダメンSQL最適化-基本記事(2)

おすすめ

転載: blog.csdn.net/qq_42726883/article/details/108487443