すべてのプロダクト
Search
ドキュメントセンター

PolarDB:よくある質問

最終更新日:Jan 03, 2025

このトピックでは、エラスティック並列クエリに関するよくある質問に対する回答を示します。

読み書きモードのPolarDBクラスターエンドポイントのエラスティック並列クエリ機能を有効にするためにヒントを使用できますか?

PolarDBコンソールの [ノードの設定] ページでエラスティック並列クエリ機能を有効にすることを推奨します。 SQL文レベルでエラスティック並列クエリ機能を有効にする場合は、 /* + parallel (n) */ または /* + SET_VAR(max_parallel_degree=n) */ を使用して、クエリの並列度をnに設定できます。 2つのヒントは異なります。

  • /* + PARALLEL(n) */ ヒントを使用すると、クエリがプライマリノードにルーティングされるかどうか、またはデータ量に関係なく、エラスティック並列クエリ機能が強制的に有効になります。

  • /* + SET_VAR(max_parallel_degree=n) */ ヒントを使用する場合、エラスティックパラレルクエリ機能が有効になるかどうかは、クエリがプライマリノードにルーティングされるかどうか、クエリのコストとオプティマイザによって評価されるデータの行によって異なります。

詳細については、「並列ヒント」をご参照ください。

SQLステートメントでヒントを使用して指定した弾性並列クエリパラメーターは、コンソールで設定したパラメーターと競合していますか?

パラメータは競合していません。 ヒントで指定されたパラメーターは、現在のSQLステートメントで有効であり、コンソールで設定されたグローバルパラメーターよりも優先度が高くなります。 ただし、PolarDBコンソールの [ノードの設定] ページでエラスティックパラレルクエリパラメーターを設定することを推奨します。 詳細については、「PolarProxyの設定」をご参照ください。

4コア、8 GBメモリの汎用クラスターなど、仕様の低いクラスターにエラスティック並列クエリ機能を使用できますか?

デフォルトでは、エラスティック並列クエリ機能は、コア数が8未満のクラスターでは無効になっています。 読み取り専用ノードに多くのアイドル状態のコンピューティングリソースがあると判断した場合は、ワークロードに応じて並列クエリを有効にできます。 ただし、並列処理の程度をコア数より高く設定しないことを推奨します。 さらに、エラスティック並列クエリ機能の制限を解除するには、max_parallel_workersパラメーターの値を大きくする必要があります。 このパラメーターをCPUコア数の2倍に設定することを推奨します。 詳細については、「DOPポリシー」をご参照ください。

単一のPolarDBテーブルに数億行のデータがある場合、パーティションテーブルまたはエラスティック並列クエリ機能を使用しますか?

エラスティック並列クエリ機能は、パーティションテーブルと共存できます。 パーティションテーブルはデータ管理を容易にします。 エラスティック並列クエリ機能は、複雑なクエリを高速化し、パーティションテーブルと非パーティションテーブルの両方で使用できます。 パーティションテーブルとエラスティック並列クエリ機能の詳細については、「パーティションテーブル」および「エラスティック並列クエリ」をご参照ください。

読み書き分離用のPolarDBエンドポイントが接続されている場合、エラスティック並列クエリ機能を有効にできますか?

はい。

スケーリングでCPUコアの数が増加した場合、PolarDBは並列クエリ用に新しく追加されたCPUコアにスレッドを自動的に割り当てますか?

はい。PolarDBは、新しく追加されたCPUコアにスレッドを自動的に割り当てます。

並列クエリはクラスタータイプとカーネルバージョンによって異なりますか?

異なるクラスタタイプは、異なるハードウェアリソース (CPUコアの数など) を有する場合があり、これは並列性の程度に影響を及ぼす場合がある。 異なるPolarDBカーネルバージョンは、並列クエリの使用に影響します。 エラスティック並列クエリ機能は、PolarDB for MySQL 8.0でのみサポートされ、PolarDB for MySQL 5.6またはPolarDB for MySQL 5.7ではサポートされません。

max_parallel_degreeパラメーターが見つからないが、PolarDBクラスターのエラスティック並列クエリ機能を有効にする場合はどうすればよいですか?

まず、現在のクラスターでエラスティック並列クエリ機能がサポートされているかどうかを確認します。 PolarDBクラスターはPolarDB for MySQL 8.0である必要があり、リビジョンバージョンは次の要件を満たす必要があります。

  • シングルノードelastic parallelクエリ: 8.0.1.0.5以降、または8.0.2.1.4.1以降。

  • マルチノードエラスティックパラレルクエリ: 8.0.2.2.6以降。

エラスティック並列クエリ機能を有効にするには、次の操作を実行することをお勧めします。[概要] ページの [クラスターエンドポイント] セクションで [変更] をクリックします。 [ノードの設定] ダイアログボックスで、並列度と並列クエリエンジンを設定します。 詳細については、「PolarProxyの設定」をご参照ください。

大量のデータがPolarDBクラスターのGROUP BYまたはORDER BY操作に関与し、非常に大きな一時テーブルが作成された場合はどうすればよいですか?

この問題の根本的な原因は、クエリの一時テーブルに大きくて密なデータが生成されることです。 この問題を解決するには、マルチノードエラスティックパラレルクエリ機能を有効にします。 詳細については、「概要」をご参照ください。

エラスティック並列クエリ機能を有効にすると、さまざまなクラスター仕様に適した並列度の値は何ですか?

並列度の初期値は、クラスター内のCPUコア数の1/4に設定することを推奨します。 たとえば、クラスターに16コアがある場合、並列度の初期値を4に設定することを推奨します。 エラスティック並列クエリ機能を有効にした後、クラスターのワークロードが低い場合は、並列処理の程度を上げることができます。

  • PolarDB For MySQL 8.0.1では、単一ノードのエラスティック並列クエリ機能のみがサポートされています。 並列処理の程度をCPUコア数の1/2を超えないようにすることを推奨します。

  • PolarDB For MySQL 8.0.2では、マルチノードelastic parallelクエリ機能もサポートされています。 複数の読み取り専用ノードが使用されている場合は、単一ノードの並列性を高めることができます。 たとえば、クラスターに2つの読み取り専用ノードがあり、それぞれが8つのCPUコアを使用する場合、並列処理度を4に設定できます。 この場合、8つのスレッドが開始されて、2つのノードで単一のクエリを実行し、クエリを高速化します。

PolarDBでエラスティック並列クエリ機能を有効にした後、ワークロードに基づいて並列処理の程度を調整するにはどうすればよいですか?

たとえば、クラスター内のノードに16個のCPUコアがある場合、並列処理度の初期値を4に設定できます。 エラスティック並列クエリ機能を有効にした後、いくつかの完全なビジネスサイクルでクラスターのワークロードの変化を観察します。 クラスターにアイドルリソースがある場合は、並列度を6に調整してから、クラスターのワークロードの変更を再度確認します。 このようにして、並列度を徐々に調整することができます。

説明

CPU使用率とメモリ使用量を確認して、クラスターにアイドルリソースがあるかどうかを確認できます。 CPU使用率が50% 以下で、メモリ使用率が80% 以下の場合、クラスターにアイドルリソースがあると判断できます。 PolarDB for MySQL 8.0.2クラスターでは、単一のクエリを複数のノードに分散して、クエリ効率をさらに向上させることができます。 したがって、単一ノードの並列性を高めることができます。

並列度の値が大きいと悪影響がありますか?

エラスティック並列クエリ機能は、複数のCPUコアを同時に使用してクエリを高速化するために使用されます。 エラスティック並列クエリ機能は、追加のコンピューティングリソースを占有します。 並列処理度の値が大きいと、クラスタのワークロードが高くなる可能性があります。 並列度の値をクラスター内のCPUコア数の1/4に設定することを推奨します。 CPUコアの数よりも高い並列度を設定しないでください。 PolarDB for MySQL 8.0.2クラスターに複数の読み取り専用ノードがある場合、マルチノードelastic parallelクエリ機能を有効にして、並列処理度の値を上げることができます。

エラスティック並列クエリ機能を有効にすると、すべてのクエリが加速されますか?

すべてのクエリが並列に実行されるわけではありません。 次の場合、クエリは並行して実行されません。

  • 並列クエリはサポートされていません。 詳細については、「並列クエリの制限」をご参照ください。

  • スキャンされたデータまたはコストの行が、並列クエリのしきい値を下回っています。 records_threshold_for_parallelismおよびcost_threshold_for_parallelismパラメーターは、並列クエリのレコードとコストのしきい値を定義します。

  • クラスターのワークロードが高すぎる場合、クエリは並列に実行されなくなります。 詳細については、「システムリソース使用量に基づくDOP制御」をご参照ください。

parallel_degree_policyパラメーターのREPLICA_AUTO値とTYPICAL値の違いは何ですか

REPLICA_AUTOは、エラスティックパラレルクエリ機能がプライマリノードで無効になり、読み取り専用ノードでのみ有効になることを示します。 クエリが並列に実行されるかどうかは、リアルタイムのワークロードによって異なります。 TYPICALは、プライマリノードでelastic parallelクエリ機能が有効になっており、リアルタイムワークロードが考慮されていないことを示します。

説明

parallel_degree_policyがTYPICALに設定されている場合、PolarDBはデータベースのリソース使用量 (CPU使用率など) を無視し、並列度 (DOP) をmax_parallel_degreeパラメーターの値に設定します。

エラスティック並列クエリ機能を有効にした後、クエリが並列に実行されるかどうかを判断するにはどうすればよいですか?

EXPLAINステートメントを実行して、クエリが並列実行されているかどうかを確認できます。 クエリが並行して実行される場合、parallel Scan (4 workers) 情報はExtraフィールドに含まれます。 詳細については、「エラスティック並列クエリ実行プランの表示」をご参照ください。

説明

クラスターエンドポイントが読み取りおよび書き込みモードの場合、プライマリノードでは弾性並列クエリ機能がデフォルトで無効になっているため、EXPLAINステートメントはプライマリノードにルーティングされます。 EXPLAINの結果は不正確かもしれません。 正確な結果を得るには、/* FORCE_SLAVE * /EXPLAIN select count(*) from t1などのヒントをexplainステートメントに追加する必要があります。

EXPLAINステートメントがSQLクエリが並列実行されることを示しているのに、クエリパフォーマンスが大幅に改善されないか、まったく改善されないのはなぜですか

並列クエリは、次の理由によりあまり高速化されません。

  • 実行プランを表示するには、explain /* + FORCE_SLAVE() */ SELECT...ステートメントを使用して、実行計画が完了しているかどうか、およびクエリが並行して実行されるかどうかを判断します。 EXPLAIN結果にParallel Scan情報が表示されている場合は、並列クエリです。

  • 並列クエリでは、大規模クエリタスクは、同時実行のために複数の小規模クエリタスクに分割される。 クエリに含まれるデータが少量の場合、クエリタスクはいくつかのサブタスクに分割されるだけです。 例えば、並列度が4に設定されているが、関連するデータ量が少ない場合、最大で2つのサブタスクのみが分割される。 この場合、加速結果はサブタスクの最大数に依存します。 PolarDB For MySQL 8.0.1クラスターの場合、Parallel Scanキーワードに続くワーカーの数は、並列スレッドの数を示します。 PolarDB For MySQL 8.0.2クラスターの場合、with parallel partitionsのキーワードに続く数は、生成されるシャードの数です。 シャードの数がmax_parallel_degree値より少ない場合、一部のワーカーはアイドル状態になり、クエリのパフォーマンスは期待どおりに向上しません。

  • 並列クエリの実行には、1つのリーダースレッドと複数のワーカースレッドが含まれます。 ワーカースレッドは並列コンピューティングを実装し、リーダースレッドは結果を集約して返します。 クエリ文のすべての演算子が実行のためにワーカースレッドにプッシュされるわけではありません。 一部の演算子はリーダースレッドで実行されます。 リーダースレッドは、単一スレッドのボトルネックにより、演算子の実行に時間がかかります。 これは加速結果に影響を与える。

  • クラスターのワークロードが不安定です。 EXPLAINステートメントを実行すると、ワークロードが低くなり、並列クエリを使用できると判断されます。 クエリの実行時にワークロードが高くなると、実際にはシーケンシャル実行が使用されます。 この場合、パフォーマンスモニタリングを使用して、ワークロードのジッタを確認できます。

PolarDBがオフセットまたは制限クエリを使用し、ソート条件が指定されていない場合、並列クエリの結果が不安定になるのはなぜですか?

ソート条件が指定されていない場合、クエリの結果はクエリのセマンティクスに関して不安定になることが予想されます。 elastic parallelクエリ機能が有効になる前はクエリ結果が安定していますが、elastic parallelクエリ機能が有効になるとクエリ結果が不安定になります。 PolarDBは、クエリ結果が安定していることを保証しません。 クエリ結果は、クエリが常に同じインデックスにヒットした場合にのみ安定します。 そうでない場合、PolarDBは安定したクエリ結果を保証できません。

プライマリノードでエラスティック並列クエリ機能が無効になっている場合はどうなりますか?

エラスティック並列クエリ機能はシステムリソースを消費します。 したがって、エラスティック並列クエリ機能を有効にすると、プライマリノードのワークロードが増加します。 デフォルトでは、プライマリノードでエラスティック並列クエリ機能は有効になっていません。 書き込むデータと必要な書き込みスループットの両方が低い場合は、プライマリノードでelastic parallelクエリ機能を有効にし、並列度を指定して、parallel_degre_policyパラメーターをAUTOまたはTYPICALに設定することもできます。

エラスティック並列クエリ機能を有効にし、innodb_adaptive_hash_indexパラメーターをonに設定すると、クエリのパフォーマンスが低下するのはなぜですか?

並列クエリにより、同じBツリーを頻繁にクエリするスレッドが増えます。 構築されたハッシュインデックスは時々失敗し、競合の問題を引き起こす可能性があります。 これらはクエリのパフォーマンスを低下させる可能性があります。 詳細については、「概要」をご参照ください。