AnalyticDB:統計値

概要

クエリオプティマイザは、クエリを実行エンジンによって実行される実行プランに変換します。 実行プランの品質は、クエリのパフォーマンスに影響します。 統計を使用して、クエリオプティマイザが高品質の実行計画を生成するのに役立ちます。

AnalyticDB for MySQLは、自動統計収集機能を提供します。 デフォルトでは、この機能は有効になっています。 V3.1.9.2以降のAnalyticDB for MySQLクラスターは、列グループ統計収集機能も提供します。 デフォルトで、この機能は無効化されています。 この機能は手動で有効にできます。 メンテナンス期間内に、AnalyticDB for MySQLは、現在のテーブルのデータ量に基づいて、基本、ヒストグラム、および列グループ統計の完全な収集またはサンプリングされた収集を自動的に実行します。 多数の列が含まれている場合、列の完全な収集を実行するには数日かかる場合があります。 メンテナンス期間外では、AnalyticDB for MySQLは基本的な統計を定期的に段階的に収集します。

AnalyticDB for MySQLの統計収集ポリシーは、データのインポート方法によって異なります。

• INSERT OVERWRITEを使用してデータをバッチインポートした場合、データインポートの完了後、AnalyticDB for MySQLはすぐに基本統計を収集します。

• INSERT INTOまたはREPLACE INTOを使用してデータをリアルタイムでインポートした場合、AnalyticDB for MySQLは、次のメンテナンス期間または各BUILDジョブが完了した後の増分収集期間まで、増分収集ジョブを開始しません。 データのインポート後に基本統計を手動で収集することを推奨します。

自動統計収集機能を無効にし、ANALYZE TABLEステートメントを実行して統計を収集することもできます。 詳細については、このトピックの「手動で統計を収集する」セクションを参照してください。

AnalyticDB for MySQLの自動統計収集機能は、内部テーブルを管理しますが、外部テーブルは管理しません。 AnalyticDB for MySQLの手動統計収集機能は、内部テーブルと外部テーブルの両方を管理します。

使用上の注意

統計の分類と選択

AnalyticDB for MySQLは、基本統計、ヒストグラム統計、列グループ統計の3種類の統計を収集します。 ヒストグラムおよび列グループの統計には、完全収集方法またはサンプリング収集方法を使用できます。 基本的な統計には、完全、サンプリング、または自動の増分収集方法を使用できます。 デフォルトでは、自動増分収集が使用されます。

基本統計

基本的な統計には、最大値、最小値、平均長 (バイト単位) 、異なる値の数、および列内のNULL値の割合が含まれます。

ヒストグラム統計

ヒストグラムは、基本統計をデータ範囲ごとにデータバケットに分割することによって作成されます。 ヒストグラムの各バケットは、特定の範囲内のデータの特性を記述します。

ヒストグラム統計は、不均一に分散されたデータを含み、フィルタリングおよび結合操作に関与する列に適しています。 データが均等に分散されている場合、基本統計を使用して、フィルタリングと結合操作を含むシナリオのヒストグラム統計を置き換えることができます。

基本統計と比較して、ヒストグラムはテーブルに関する統計をより正確に反映できます。 多数のテーブルが含まれる場合、すべての列のヒストグラム統計を収集すると、キャッシュヒット率が低下する可能性があります。 ヒストグラム統計は、基本統計よりも多くの統計キャッシュを占有し、コストが高くなります。 デフォルトでは、統計キャッシュには約20,000列のヒストグラム統計または200万列の基本統計を含めることができます。

列グループ統計

基本およびヒストグラム統計は、個々の列で収集される。 列グループ統計は、テーブルの複数の列で収集され、これらの列が互いにどのように相関するかを説明します。

列グループ統計は、複数の列を集約するのに適しています。 列同士の相関性が高い場合は、列グループ統計を使用して出力行数を見積もることができます。 これにより、適切な実行プランを選択できます。

自動統計収集

自動統計収集機能の有効化または無効化

SET adb_config O_CBO_AUTONOMOUS_STATS_ENABLED = [false | true];

自動列グループ統計収集機能の有効化または無効化

SET adb_config O_CBO_MAINTENANCE_WINDOW_COLLECT_GROUP_STATS_ENABLED = [false | true];

メンテナンス期間の設定

SET adb_config O_CBO_MAINTENANCE_WINDOW_DURATION = [04:00-05:00];

統計収集のデータ量のしきい値を設定する

SET adb_config O_CBO_MAINTENANCE_WINDOW_COLLECTOR_ROW_LIMIT = 10000;

統計収集のスキャン調整を有効または無効にする

SET adb_config O_CBO_AUTONOMOUS_STATS_SCAN_RATE_LIMIT_ENABLED = [false | true];

指定したリソースグループから統計を収集する

SET adb_config O_CBO_AUTONOMOUS_STATS_ACCOUNT = [user_name];

列の有効期限率を設定する

SET adb_config O_CBO_STATS_EXPIRED_RATIO = 0.1;

手動で統計を収集する

ANALYZE TABLE [schema_name.]table_name [UPDATE [BASIC | HISTOGRAM | GROUP_STATS]] [ON column_name[,...]] [ENABLE SAMPLING]

ANALYZE TABLE table_name WITH PARTITIONS = ARRAY[ARRAY[PARTITION_KEYS] [, PARTITION_KEYS, ....]]

クエリ統計

よくある質問

ANALYZEステートメントが遅いクエリと誤診されるのはなぜですか?

メンテナンス期間中に自動的に開始されるANALYZEステートメントは、I/Oスロットリングと低いCPU優先度で実行されます。 ステートメントは、長期間実行されるため、低速クエリと診断される場合があります。 ただし、これはサービスには影響しません。 CPU負荷が高くない場合、またはCPUの過負荷がメンテナンスウィンドウと密接に関連していない場合は、この問題を無視できます。 CPUが継続的にオーバーロードされている場合、この問題を解決するには、このトピックの「統計収集によって引き起こされるCPUオーバーロードによってクエリ応答時間が影響を受ける場合はどうすればよいですか」を参照してください。

統計機能を使用すると、なぜCPUオーバーロードが発生するのですか?

次の理由により、CPUが過負荷になることがあります。

• 04:00から05:00までのデフォルトのメンテナンス期間中に、システムは各テーブルでフルスキャンを実行して列統計を収集します。 この期間中、CPUは過負荷になります。

• ほとんどの場合、統計は増分的に収集され、大量のリソースを消費しません。 デフォルトでは、統計機能はV3.1.6以降を実行するAnalyticDB for MySQL Data Warehouse Edition (V3.0) クラスターで有効になっています。 クラスターが以前のマイナーバージョンからV3.1.6以降に更新されると、完全な統計が収集されます。 これにより、マイナーバージョンの更新後の最初の日にCPUがオーバーロードする可能性があります。 CPU負荷は、フルデータスキャンが完了した後に減少する。

CPUが過負荷になっている場合は、クエリの応答時間に影響があるかどうかを確認します。 平均クエリ応答時間が大きく変化しない場合、クエリ応答時間は影響を受けません。 CPU利用率メトリックの値は、統計収集中は高い場合があるが、クエリが実行されると、実行のためにリソースが優先的に割り当てられる。 これは、ANALYZEステートメントがI/Oスロットリングと低いCPU優先度で実行されるためです。

クエリの応答時間が統計収集によって引き起こされるCPUの過負荷の影響を受ける場合はどうすればよいですか?

この問題は、次のソリューションを使用して解決できます。

• メンテナンス期間をオフピーク時間に変更します。

  adb_config O_CBO_MAINTENANCE_WINDOW_DURATION = [04:00-05:00];

• 適切なオフピーク時間が特定できない場合は、システムクエリのI/O制限を16 MB以上の値に変更することを推奨します。 デフォルト値は50 MBです。

  set adb_config CSTORE_IO_LIMIT_SYSTEM_QUERY_BPS = 52428800;

• 統計コレクションを優先度の低いリソースグループに割り当てて、負荷を分離します。 詳細については、「統計」トピックの「自動統計収集」セクションをご参照ください。

  set adb_config O_CBO_AUTONOMOUS_STATS_ACCOUNT = [user_name];

• 列の有効期限を増やして、収集するデータを減らします。 デフォルト値は 0.1 です。 値の範囲は0〜1です。 有効期限の比率を0.5を超える値に設定しないことを推奨します。

  adb_config O_CBO_STATS_EXPIRED_RATIO = 0.1を設定します。

上記のソリューションでこの問題が解決されない場合は、set adb_config O_CBO_AUTONOMOUS_STATS_ENABLED=false; ステートメントを実行して、自動統計収集を無効にします。 しかしながら、性能が低下する可能性がある。 将来統計を収集したい場合は、手動で統計を収集する必要があります。 詳細については、「統計」トピックの「統計の手動収集」セクションをご参照ください。

SELECT * FROM INFORMATION_SCHEMA.COLUMN_STATISTICSの実行結果は、統計が数日間更新されないことを示しています。 これはなぜですか。

この問題は、以下の理由により生じます。

• 統計は期限切れではありません。

  更新、挿入、または置換されたデータの量が有効期限の比率に達すると、統計は期限切れになります。 デフォルトの有効期限は0.1 (10%) です。 少量のデータしか変更されていない場合は、クラスターを期待どおりに使用し続け、この問題をさらに1週間観察できます。

• 大量のデータが多くの列とテーブルに含まれています。

  デフォルトでは、増分更新に含まれない統計を収集するには、1日1時間のみ必要です。 1,000を超える列など、多数の列とテーブルが関係する場合、システムは1日以内に更新を完了できない可能性があります。 更新が完了するまでに1週間かかる場合があります。 この場合、数日以内に統計更新がないのは正常です。 引き続きクラスターを使用して、この問題を確認できます。

データが新しいテーブルにインポートされた後、統計は自動的に更新されますか?

INSERT OVERWRITEステートメントを使用してデータをバッチインポートすると、データのインポート完了後に基本統計が自動的に収集されます。 INSERT INTOまたはREPLACE INTOステートメントを使用してデータをリアルタイムでインポートすると、次のメンテナンス期間中に統計が収集されるか、各BUILDタスクが完了した後の増分収集期間中に増分収集タスクがトリガーされます。 データのインポート後に基本統計を手動で収集することを推奨します。 詳細については、「統計」トピックの「統計の手動収集」セクションをご参照ください。