一般的な問題と改善策 - AnalyticDB - Alibaba Cloud ドキュメントセンター

データ分散の偏りや複雑なクエリなどの要因により、クエリのパフォーマンスが期待に応えられない場合があります。潜在的なパフォーマンスの問題を特定する1つの方法は、実行計画を確認することです。

クエリのパフォーマンスに影響する一般的な問題

結合方法と内部および外部テーブル
通常、AnalyticDB for MySQLは、joinメソッドに基づいて、内部結合と外部結合にアクセスする左右のテーブルを決定します。
ハッシュ結合では、右のテーブルがハッシュテーブルを構築するために使用され、左のテーブルはハッシュ一致についてハッシュテーブルをプローブする。通常、追加のオーバーヘッドを防ぎ、ハッシュテーブルのサイズを減らすために、右側のテーブルは左側のテーブルよりもサイズが小さくなければなりません。テーブルが結合およびフィルタリングされた後、データエントリの数を確認して、左右のテーブルが適切な方法で選択されているかどうかを判断できます。しかしながら、中間結合結果および結合タイプなどの他の要因は、左右のテーブルの選択を複雑にする。
注文に参加する
クエリオプティマイザの主な課題の1つは、結合順序を最適化することです。これも古典的なNP困難な問題です。 AnalyticDB for MySQLのクエリオプティマイザは、異なる負荷に対して2つの結合並べ替えポリシーを提供します。左ディープツリー (LDT) とブッシーツリー (BT) です。 LDTポリシーは単純なクエリに適しており、BTポリシーは複雑なクエリに適しています。 BTポリシーにより、効率的なフィルタリングを可能にするテーブルを最初に結合して、複雑なクエリの最適な結合順序を生成できます。
複雑なクエリの最適な結合順序は、エンジニアが決定するのが困難です。多数のテーブルがデータ集約型クエリに結合されている場合、クエリの最適化を実行するには上級エキスパートが必要です。効率的なフィルタリングを可能にするテーブルを結合順序で優先することを推奨します。これにより、不要なデータを早期にフィルタリングするための迅速な方法が提供されます。
分散集計
AnalyticDB for MySQLは、データボリュームに基づいて複数の段階で集計操作を実行できる分散集計機能を提供します。ほとんどの場合、AnalyticDB for MySQLのクエリオプティマイザは最適な集計プランを選択できます。ただし、データ分布が偏っている場合、クエリオプティマイザは不正確な推定を行います。これは、集約のパフォーマンスに影響します。たとえば、AnalyticDB For MySQLは2段階で集計を実行します。最初の段階では、AnalyticDB for MySQLは各計算ノードで部分的な集約を実行します。これにより、集約するデータの量が少なくなります。第2段階では、AnalyticDB for MySQLは、集約された列の再編成に基づいて最終集約を実行します。データ分布が偏っているか、または集約されるいくつかの列が一意である場合、部分集約は集約されるデータの量を減らすことができませんが、追加のパフォーマンスオーバーヘッドを引き起こします。
その他の問題
このトピックでは、実行計画に関連する一般的な問題のみを示します。複雑な問題は、AnalyticDB for MySQLのエキスパートサービスチームがトラブルシューティングする必要があります。たとえば、テーブル全体のスキャン中にフィルタ条件のない大きなテーブルが見つかったり、フィルタ条件がストレージエンジンにプッシュダウンされたりしません。

実行計画の改善

テーブル統計の収集
AnalyticDB for MySQLのクエリオプティマイザは、テーブル統計に基づいて実行計画のオーバーヘッドを推定し、最適な実行計画を選択します。統計は手動操作を必要とせずに自動的に収集されます。詳細については、「統計」トピックの「自動統計収集」セクションをご参照ください。システムが新しいテーブルの統計を収集していない場合は、SELECT * FROM information_schema.column_statistics; を実行して、information_schema.column_statisticsテーブルに新しいテーブルの統計が含まれているかどうかを確認できます。このシステムテーブルは、V3.1.6以降のクラスターでのみ使用できます。システムテーブルに新しいテーブルの統計が含まれていない場合は、自動収集の前に手動で統計を収集するステートメントを実行できます。手動で統計を収集する方法の詳細については、「統計」トピックの「手動で統計を収集」セクションをご参照ください。
結合順序の変更
AnalyticDB for MySQLは、データが不均一に分散されている、または複雑なクエリが含まれるシナリオを除いて、最適な結合順序を選択できます。クエリのパフォーマンスを向上させるために、reorder_joinsパラメーターをヒントとして導入して、結合順序を手動で変更するかどうかを指定できます。
- /* + reorder_joins=false */; ヒントを追加して、結合順序の手動変更を有効にします。次に、FROM句のテーブル名の順序を変更して、クエリの結合順序を生成できます。
- /* + reorder_joins=true */; のヒントを追加して、結合順序の手動変更を無効にします。 AnalyticDB for MySQLのクエリオプティマイザは、ほとんどの場合、最適な結合順序を自動的に生成できます。
たとえば、国、地域、顧客という名前のテーブルの場合、AnalyticDB For MySQLによって生成される結合順序は、地域> 国> 顧客です。実際のクエリパフォーマンスに基づいてcustomer > nation > regionの結合順序がより効果的であることがわかった場合は、クエリの先頭にヒントを追加して結合順序を変更できます。
```
/* + reorder_joins=false * /
       EXPLAIN SELECTカウント (*)
       顧客から、国家、地域
       WHERE c_nationkey = n_nationkey
       AND n_regionkey = r_regionkey
       AND r_name = 'ASIA'; 
```
```
| プランの概要 |
       +---------------+
       1-出力 [クエリ計画]
       2 -> 集計 (FINAL)
       3 -> LocalExchange [シングル]
       4 -> 交換 [ギャザー]
       5 -> 集合体 (部分)
       6 -> InnerJoin [ハッシュ参加]
       7-プロジェクト
       8 -> InnerJoin [ハッシュ参加]
       9 - ScanProject {table: customer}
       10 -> TableScan {table: customer}
       11 -> LocalExchange [ハッシュ]
       12 -> 交換 [REPLICATE]
       13 - ScanProject {table: nation}
       14 -> TableScan {table: nation}
       15 -> LocalExchange [ハッシュ]
       16 -> 交換 [REPLICATE]
       17 - ScanProject {table: region}
       18 -> TableScan {table: region} 
```
注文参加機能のプランヒントを有効にする
AnalyticDB for MySQLは、結合順序の変更に役立つプランヒント機能もサポートしています。 leading_join_orderヒントをクエリの先頭に追加して、AnalyticDB for MySQLの結合順序を変更できます。
説明クエリで複数回参照されるテーブルを識別しやすくするために、結合順序機能のプランヒントを使用する場合は、テーブルのエイリアスを指定する必要があります。
前の例で示したSQL文の結合順序機能のプランヒントを有効にすると、同じ結合順序が生成されます。
```
/* + leading_join_order=((c n) r) * /
      EXPLAIN SELECTカウント (*)
      国家nから、地域r、顧客c
      WHERE c_nationkey = n_nationkey
      AND n_regionkey = r_regionkey
      AND r_name = 'ASIA'; 
```

実行計画の最適化は、広い分野である。このトピックでは、AnalyticDB for MySQLの基本的な最適化方法について説明します。さらに最適化のベストプラクティスが継続的に補足されます。