Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。

# SVL\_QUERY\_SUMMARY ビューの使用
<a name="using-SVL-Query-Summary"></a>

[SVL\_QUERY\_SUMMARY](r_SVL_QUERY_SUMMARY.md) を使用して、クエリの概要情報をストリームで分析するには、以下を実行します。

1. 次のクエリを実行してクエリ ID を調べます。

   ```
   select query, elapsed, substring
   from svl_qlog
   order by query
   desc limit 5;
   ```

   `substring` フィールドの切り捨てられたクエリテキストを調べ、どの `query` 値がクエリを表しているかを確認します。クエリを複数回実行した場合、`query`値が小さい行の `elapsed` 値を使用します。これは、コンパイル済みバージョンの行です。多くのクエリを実行している場合、クエリが確実に含められるように、LIMIT 句により使用される値を大きくすることができます。

1. クエリの SVL\_QUERY\_SUMMARY から行を選択します。結果をストリーム、セグメント、ステップ順に並べ替えます。

   ```
   select * from svl_query_summary where query = MyQueryID order by stm, seg, step;
   ```

   結果の例は次のとおりです。  
![特定のクエリに一致する SVL_QUERY_SUMMARY の行のサンプル結果。](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/images/svl_query_summary_results.png)

1. 「[クエリの概要へのクエリプランのマッピング](query-plan-summary-map.md)」の情報を使用して、クエリプラン内の操作にステップをマッピングします。これらは、列およびバイト (クエリプランの行 x 幅) の値とほぼ同じになります。大きく異なる場合、「[テーブル統計がないか古い](query-performance-improvement-opportunities.md#table-statistics-missing-or-out-of-date)」で推奨される解決策を参照してください。

1. `is_diskbased` フィールドに、ステップの `t` 値がある (true) かどうかを調べます。ハッシュ、集計、およびソートは、システムでクエリ処理に十分なメモリが割り当てられていない場合に、ディスクにデータを書き込む可能性が高い演算子です。

   `is_diskbased` が true の場合、「[クエリに割り当てられてメモリが不十分](query-performance-improvement-opportunities.md#insufficient-memory-allocated-to-the-query)」で推奨される解決策を参照してください。

1. `label` フィールドの値を確認し、ステップのいずれかの場所に AGG-DIST-AGG シーケンスがあるかどうかを調べます。ある場合、コストの高い 2 ステップの集約であることを示しています。これを修正するには、GROUP BY 句を変更して分散キー (複数ある場合は 1 番目のキー) を使用します。

1. 各セグメントの `maxtime` 値を確認します (セグメントのすべてのステップ間で同じです)。`maxtime` 値が最も大きいセグメントを特定し、このセグメント内のステップで次の演算子を確認します。
**注記**  
`maxtime` 値が大きくても、セグメントに問題があるとは限りません。値が大きくても、セグメントの処理に時間がかからないことがあります。ストリーム内のすべてのセグメントは同時に開始します。ただし、ダウンストリームセグメントによっては、アップストリームセグメントからデータを取得するまで実行できません。そのセグメントの `maxtime` 値には待機時間と処理時間の両方が含まれるため、この効果により長時間かかるように見えることがあります。
   + **BCAST または DIST**: これらの場合、`maxtime`値が大きいと多数の行が再分散される可能性があります。推奨される解決策については、「[十分最適でないデータ分散](query-performance-improvement-opportunities.md#suboptimal-data-distribution)」を参照してください。
   + **HJOIN (ハッシュ結合)**: 問題のステップの `rows` フィールド内の値が、クエリ内の最後の RETURN ステップの `rows` 値と比較して非常に大きい場合、「[ハッシュ結合](query-performance-improvement-opportunities.md#hash-join)」で推奨される解決策を参照してください。
   + **SCAN/SORT**: 結合ステップの直前にあるステップの SCAN、SORT、SCAN、MERGE シーケンスを探します。このパターンは、未ソートのデータがスキャン、ソートされた後、テーブルのソート済み領域とマージされます。

     SCAN ステップの行の値が、クエリ内の最後の RETURN ステップにある行の値と比較して非常に大きいかどうかを確認します。このパターンは、後で破棄される行を実行エンジンがスキャンしていることを示します (非効率的です)。推奨される解決策については、「[述語の制限が不十分](query-performance-improvement-opportunities.md#insufficiently-restrictive-predicate)」を参照してください。

     SCAN ステップの `maxtime` 値が大きい場合、「[十分最適でない WHERE 句](query-performance-improvement-opportunities.md#suboptimal-WHERE-clause)」で推奨される解決策を参照します。

     SORT ステップの `rows` 値がゼロ以外の場合、「[未ソート行または正しくソートされていない行](query-performance-improvement-opportunities.md#unsorted-or-mis-sorted-rows)」で推奨される解決策を参照してください。

1. 最後の RETURN ステップの前にある 5～10 個のステップの `rows` 値と `bytes` 値を確認し、クライアントに返されるデータの量を調べます。このプロセスには少し工夫が必要です。

   例えば、次のクエリの概要では、3 番目の PROJECT ステップにより `bytes` 値ではなく `rows` 値が提供されています。先行するステップで同じ `rows` 値を持つステップを探すと、行とバイトの両方の情報を提供する SCAN ステップが見つかります。

    結果の例を次に示します。  
![行とバイトの両方の情報を含む SCAN ステップであるクエリの概要の結果の行。](http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/images/rows_and_bytes.png)

   非常に大量のデータを返す場合、「[非常に大きな結果セット](query-performance-improvement-opportunities.md#very-large-result-set)」で推奨される解決策を参照してください。

1. 他のステップと比較して、いずれかのステップの `bytes` 値が `rows` 値より大きいかどうかを確認します。このパターンは、多くの列を選択していることを示す場合があります。推奨される解決策については、「[大きい SELECT リスト](query-performance-improvement-opportunities.md#large-SELECT-list)」を参照してください。