AnalyticDB for MySQLは、SQL診断機能を提供し、クエリ、ステージ、および演算子レベルでSQLクエリ情報の統計を個別に収集し、統計を使用して問題を診断し、最適化の提案を提供します。 このトピックでは、オペレータレベルの診断結果を表示および分析する方法について説明します。
診断結果タイプ
オペレータレベルの診断結果を表示する方法の詳細については、「診断結果の表示」をご参照ください。
集計演算子の集計率が低い
問題
集計演算子の集計率は、GROUP BY列に基づいてデータをグループ化し、各グループに集計した後の、入力データサイズと出力データサイズの比率を指します。 より低い比は、より低い凝集率およびより悪い凝集効果を示す。 AnalyticDB for MySQLでは、GROUP BY操作は、部分集約と最終集約の2つのステップで構成されます。 多数の集約演算子グループは、低い集約率を引き起こす可能性がある。 部分集約ステップでは、ネットワークを介して転送されるデータの量を減らすことはできないが、大量の計算リソースが消費される。
提案
部分集約ステップをスキップし、各ノード間でデータを再分配してから、最終集約を実行することができます。 詳細については、「グループ化と集計クエリの最適化」をご参照ください。
フィルター条件が押し下げられない
問題
デフォルトでは、AnalyticDB for MySQLは、データストレージ中にテーブル内のすべての列のインデックスを作成します。 これらのインデックスを使用して、データのクエリ時にデータのフィルタリングを高速化できます。 次のシナリオでは、AnalyticDB for MySQLはフィルター条件をプッシュダウンしません。
クエリ文で
no_index_columnsまたはfilter_not_pushdown_columnsヒントが使用されている場合、またはクラスターでadb_config filter_not_pushdown_columns構成が使用されている場合、フィルター条件のプッシュダウン機能は無効になります。CASTなどの関数は、フィルタ条件で使用されます。フィルター条件の関連列にはインデックスがありません。 たとえば、テーブルを作成するときに
no_indexキーワードを使用したり、テーブルの作成後にno_indexステートメントを実行してインデックスを削除したりします。
提案
クエリ文でヒントが使用されているか、クラスターが設定を使用しているためにフィルター条件のプッシュダウン機能が無効になっている場合は、ヒントまたは設定が使用されている理由を確認し、ヒントまたは設定をキャンセルできるかどうかを判断します。 詳細については、「プッシュダウンなしの条件のフィルタリング」をご参照ください。
関数を使用する場合は、関数を直接使用してデータを書き込み、クエリ中に関数を削除するかどうかを選択できます。
フィルター条件の関連列にインデックスがないためにフィルター条件が押されない場合は、列にインデックスがない理由を確認する必要があります。
結合でデータ拡張が発生する
問題
結合のデータ拡張率は、入力行の数に対する出力行の数の比である。 入力行数は、左テーブルの行数と右テーブルの行数の合計です。 適切な結合条件のために、出力行の数は入力行の数よりも少ない。 出力行の数が入力行の数よりも多い場合、データの拡張が発生します。 これにより、大量のコンピューティングおよびメモリリソースが占有される。 したがって、クエリが遅くなります。
提案
結合でのデータ拡張が、左右両方のテーブルの重複する値の数が多いなどのデータ特性に起因する場合は、結合から重複するすべての値を除外できます。
データ拡張が不適切な結合順序によって引き起こされた場合は、手動で結合順序を調整できます。 詳細については、「結合注文の手動調整」をご参照ください。
結合の正しいテーブルのサイズが大きい
問題
AnalyticDB for MySQLでは、結合内の正しいテーブルは、メモリ内のハッシュまたはセット構造を構築するために使用されるビルダーテーブルを参照します。 サイズが大きい右側のテーブルは、大量のメモリリソースを占有し、クラスタの全体的な安定性に影響を与える可能性があります。 次の理由により、結合の右側のテーブルのサイズが大きくなる場合があります。
SQL文にはLEFT JOIN句が含まれています。 左結合の右のテーブルは、実行中にビルダーテーブルとして使用する必要があります。 左側の結合の右側のテーブルのサイズが大きい場合、大量のメモリリソースが消費されます。
AnalyticDB for MySQLが左右のテーブルのデータサイズを推定する場合、統計の有効期限などの理由で推定が不正確になります。
提案
左の結合を右の結合に書き直すことを推奨します。 詳細については、「左結合を右結合に書き直す」をご参照ください。
クロス結合が存在する
問題
交差結合は、結合条件のないjoin操作であり、結合の左右のテーブルから行のデカルト積を返します。 左右両方のテーブルのサイズが大きい場合、AnalyticDB for MySQLクラスターの安定性に大きな影響があります。
提案
結合条件を追加して、交差結合を排除することができます。
スキャン演算子が多数の列を読み取る
問題
スキャンオペレーターは、AnalyticDB for MySQLのストレージレイヤーでデータをフィルタリングし、詳細データを読み取ります。 SELECTステートメントに多数の列が含まれ、大量の詳細データが読み取られると、大量のディスクI/Oリソースが占有され、AnalyticDB for MySQLクラスターの全体的な安定性に影響を与えます。
提案
SQL文を最適化して、SELECT文の不要な列を減らすことができます。
スキャンしたデータ量にデータスキューが発生
問題
AnalyticDB for MySQLは分散実行アーキテクチャです。 通常、大きなテーブルのデータには配布列を指定する必要があります。 データの書き込み時には、分配列に基づいて異なるストレージノードにデータが分配される。 分散列の値が不均等に分散している場合、各ノードにはデータが不均等に格納されます。 データが読み取られると、各ノードには長い時間テールがあり、最終的なクエリ効果に影響します。
提案
適切な配布列を選択して、スキャンデータ量のデータスキューを軽減できます。 詳細については、「配布フィールドのスキューに関する診断」をご参照ください。
インデックスは非効率的です
問題
AnalyticDB for MySQLがインデックスを使用してデータをフィルタリングし、フィルタ演算子の入力と出力のデータサイズの比率が低い場合、期待どおりにインデックスでデータがフィルタリングされない場合があります。
提案
フィルター条件をプッシュダウンする代わりに、計算ノードでフィルター操作を使用することを選択できます。 詳細については、「プッシュダウンなしの条件のフィルタリング」をご参照ください。