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/)を参照してください。
# インターリーブソートキー
インターリーブソートキーは、ソートキー内の各列または列のサブセットに同じ重み付けをします。複数のクエリが 1 つのフィルターで異なる列を使用する場合、インターリーブソート形式を使用することで、多くの場合これらのクエリのパフォーマンスが向上します。クエリがセカンダリソート列で制限述語を使用する場合、インターリーブソートは複合ソートに比べて大幅にクエリのパフォーマンスが向上します。
**重要**
ID 列、日付、タイムスタンプなど、一定間隔で増加する属性を持つ列で、インターリーブソートキーを使用しないでください。
インターリーブソートキーの実行によって得られるパフォーマンスの改善は、ロードの増分とバキューム処理の回数によって異なります。
インターリーブソートは、例えば `select c_name from customer where c_region = 'ASIA'` のように WHERE 句のソートキー列をフィルタリングする非常に選択的なクエリの場合に最も効果的です。インターリーブソートの効果は、制限されたソート済み列の数で向上します。
インターリーブソートは大きなテーブルに対してより効果的です。ソートは各スライスに適用されます。したがって、スライスごとに 1 MB のブロックを複数必要とする大きなテーブルの場合、インターリーブソートが最も効果的です。ここで、クエリプロセッサは、制限述語を使用してブロックのかなりの割合をスキップできます。テーブルが使用するブロック数を表示するには、[STV\$1BLOCKLIST](r_STV_BLOCKLIST.md) システムビューに対してクエリを実行します。
単一の列を並べ替える場合、列の値に長い共通プレフィックスがある場合は、インターリーブソートの方が複合ソートよりもパフォーマンスがいい場合があります。例えば、URL は一般的に「http://www」で始まります。複合ソートキーはプレフィックスから使用する文字数に制限があるため、大量のキーの重複が発生します。インターリーブソートは、ゾーンのマッピング値に内部圧縮方式を使用するため、長い共通プレフィックスがある列の値をよりよく識別できます。
小さな Amazon Redshift プロビジョニングクラスターを Amazon Redshift Serverless に移行すると、Redshift はインターリーブソートキーと DISTSTYLE KEY の両方を持つテーブルを複合ソートキーに変換します。ただし、インターリーブソートキーのみを持つテーブルは変更されません。分散スタイルの詳細については、「[データディストリビューションスタイルの操作](https://docs.aws.amazon.com//redshift/latest/dg/t_Distributing_data.html)」を参照してください。
**VACUUM REINDEX**
すでにデータが含まれているソート済みテーブルに行を追加すると、パフォーマンスが時間とともに悪化することがあります。この悪化は複合ソートとインターリーブソートの両方で発生しますが、インターリーブテーブルでより影響が大きくなります。VACUUM はソート順序を復元しますが、インターリーブテーブルの場合は操作に時間がかかります。これは、新規のインターリーブデータのマージを行う際に各データブロックの変更が必要になる場合があるためです。
テーブルが最初にロードされると、Amazon Redshift がソートキー列の値の分散を分析し、その情報を基に適切なインターリービングをソートキー列に実行します。テーブルが大きくなるにつれて、ソートキー列の値の分散は、特に日付またはタイムスタンプ列で、変化したり不均等になったりします。不均等が大きくなりすぎると、パフォーマンスに影響を与えます。ソートキーを再分析してパフォーマンスを復元するには、REINDEX キーワードとともに VACUUM コマンドを実行します。インターリーブテーブルの場合、データに対して追加の分析パスを取る必要があるため、VACUUM REINDEX は標準の VACUUM よりも時間がかかります。キーの分散スキューおよび直近のインデックス再作成時間を表示するには、[SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) システムビューにクエリを実行します。
VACUUM の実行頻度および VACUUM REINDEX の実行時期についての詳細は、「[インデックスを再生成するかどうかの決定](vacuum-managing-vacuum-times.md#r_vacuum-decide-whether-to-reindex)」を参照してください。