このトピックでは、の一般的なスロークエリとその原因について説明します。
メモリリソースを消費する低速クエリ
Peak memoryパラメーターで指定したクエリの最大メモリは、メモリ使用量の評価に役立ちます。 通常、最大メモリが大きいほど、消費されるメモリリソースが多くなります。
SQL診断機能を使用すると、特定の期間内に実行に時間がかかるクエリを検索できます。 次に、プロパティのクエリセクションまたはさまざまなレベルの診断結果で特定のクエリのピークメモリを表示できます。 詳細については、「t2103386.html#task_2103386」をご参照ください。
- GROUP BY操作はステージで実行されます。
は、GROUP BY句で参照される列の値をメモリにキャッシュします。 GROUP BY句で参照される列に複数の一意の値がある場合、大量のメモリリソースが消費されます。
- JOIN操作はステージで実行されます。
ハッシュ結合が使用される場合、はテーブルのデータをメモリにキャッシュする。 キャッシュされたテーブルのサイズが大きいほど、消費されるメモリリソースが多くなります。
- SORT操作はステージで実行されます。
データがソートされているとき、はデータをメモリにキャッシュする。 ソートする必要があるデータが多いほど、消費されるメモリリソースが多くなります。
- ウィンドウ関数はステージで実行されます。
ウィンドウ関数が実行されているとき、はデータをメモリにキャッシュする。 ウィンドウ関数によって実行する必要があるデータが多いほど、消費されるメモリリソースが多くなります。 詳細については、「ウィンドウ関数」をご参照ください。
CPUリソースを消費する低速クエリ
Time Consumedパラメーターで指定されたクエリの実行期間は、CPU使用率の評価に役立ちます。 通常、実行期間が長いほど、消費されるCPUリソースが多くなります。
SQL診断機能を使用すると、特定の期間内に実行に時間がかかるクエリを検索できます。 次に、プロパティのクエリセクションで特定のクエリの時間がかかるを表示できます。 詳細については、「t2103386.html#section_zxl_cz3_cuv」をご参照ください。
- フィルタ条件は、ストレージレイヤーに押し下げられません。 デフォルトでは、はテーブルを作成するときにすべての列のインデックスを作成します。 データのフィルタリングに使用されるインデックスは、消費されるCPUリソースを大幅に削減できます。 ただし、一部のシナリオでは、フィルタ条件が押し下げられません。 詳細については、「t2101552.html#section_b9y_az4_nre」をご参照ください。
- フィルタ操作は結合条件に存在します。 フィルター条件が結合に含まれている場合、は最初に2つのテーブルを結合し、次に結合されたデータをフィルターします。 この場合、インデックスはフィルタリングに使用できません。 結合後に大量のデータが生成された場合、フィルタ操作は大量のCPUリソースを消費します。
- 結合には結合条件が指定されていません。 結合条件が指定されていない場合、は左右のテーブルに対してデカルト積演算を実行します。 生成される行数は、左右のテーブルの行数の積である。 このタイプの操作は、大量のCPUリソースを消費します。
ディスクI/Oリソースを消費する低速クエリ
スキャン行パラメーターで指定されたスキャン行数とスキャンデータ量パラメーターで指定されたスキャンデータ量は、ディスクI/Oの使用状況を評価するのに役立ちます。 通常、スキャンされた行が多く、スキャンされたデータの量が多いほど、ディスクI/Oリソースが多く消費されます。
SQL診断機能を使用すると、指定された期間内に実行され、実行に時間がかかったクエリを検索できます。 次に、特定のクエリのスキャン行数とスキャンボリュームをプロパティのクエリセクションまたはさまざまなレベルの診断結果で表示できます。 詳細については、「t2103386.html#task_2103386」をご参照ください。
- フィルタ条件は、少量のデータのみをフィルタリングするため、インデックス効率が低くなり、多数のインデックスが読み取られます。
- フィルター条件は押し下げられません。 これにより、ソーステーブルのフルスキャンが発生します。
- フィルター条件が押し下げられます。 しかし、それらのフィルタスコープは大きく、大量のデータをスキャンしなければならない。
- 多数のパーティションをスキャンする必要があります。 通常、より多くのパーティションは、スキャンされるデータの量が多いことを示す。