SQLクエリー最適化ルーチンは、SQLリクエストに応答するために必要となるテーブルにアクセスし、結合および集約するための効率的な方法を特定します。
問合わせ最適化ルーチンが尋ねる質問とその回答
最適化ルーチンは、最良の計画を確認するというタスクを実行する際に、リクエストに関係するテーブルと列についてのさまざまなデモグラフィック情報およびシステムの構成、また多くの経験則的戦略または経験法則を使用します。
- このリクエストは増分計画および実行を使用して最適化すべきか?
- テーブルのカーディナリティ濃度は何か?
この場合のカーディナリティ濃度とは、一般的には基本テーブル内の行の数ではなく、結果またはスプール テーブル内の行の数のこと。
- テーブルの次数は何か?
この場合の次数とは、一般的にはテーブル内の列の数ではなく、結果またはスプール テーブル内の列の数のこと。
- 問合わせを処理するのに必要な列とインデックスのセットの間隔ヒストグラム統計はあるか?
- 既存の間隔ヒストグラム統計がある場合、合理的なカーディナリティの見積もりを提供するのに十分なほど新しいか、それとも古いか?
- 既存の間隔ヒストグラム統計がある場合、DATE値に渡る範囲問合わせをカバーできるか、それとも外挿法が必要か?
- テーブルは、プライマリ インデックス、プライマリAMPインデックスが含まれているか、またはプライマリ インデックスなしの状態か?
- テーブルはパーティション化されているか?
- テーブルがパーティション化されている場合、パーティション統計はあるか?
- 要求された列セットにはインデックスが付けられているか?
- 列セットにインデックスが付けられている場合は、そのインデックスは固有か非固有か?
- 行パーティション排除が適用可能か?
- 列パーティション排除が適用可能か?
- 列セット内にはいくつの固有な値があるか?
- 列セットまたはインデックス内に、統計値が収集された列に1つ以上のnullが含まれる行がいくつあるか?
- 列セットまたはインデックス内に、統計値が収集された列すべてにnullが含まれる行がいくつあるか?
- 列セット値当たり何行返されることが予測されているか?
- 基本テーブルをセカンダリ カバー インデックス、ハッシュ、または単一テーブル結合インデックスで置き換えられるか?
- 結合は、結合インデックスまたはNUSIによって、部分的に行なわれたか完全に行なわれたか?
- 結合または集約をUNION ALLブランチに後付けできるか?
- 集約を結合のリレーションに部分的に後付けできるか?
- 列の集約は、既存の結合インデックスによってすでに計算されているか?
- このタイプの問合わせについて過去に最も効果的だったのはどの戦略か?
- システム内にAMPはいくつあるか?
- システム内にノードはいくつあるか?
- 各AMPにはいくつの、またどのようなディスクがあるか、また実行中のノードの処理速度はどれくらいか?
- テーブル ロードは分離されているか?
これらの質問の多くには、一般に、SQL COLLECT STATISTICS文を使用して生成した統計データに基づいて答えるのが理想的です(<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>の「COLLECT STATISTICS (最適化ルーチン形式)」を参照)。データベース統計が定期的に収集されているなら、最適化ルーチンは最良の判定を行なうと期待できます。
最適化ルーチンはインデックス統計や列統計が必要になると、最初に統計キャッシュを確認します(統計キャッシュを参照)。必要な統計がキャッシュされていない場合、最適化ルーチンはその統計をDBC.StatsTblから取得します(DBC.StatsTblについての詳細は、<Teradata Vantage™ - データ ディクショナリ、B035-1092>を参照)。
統計が収集されていても、相当の時間が経過しているためデータのデモグラフィックを正しく反映していない場合には、最適化ルーチンは、処理法についての十分な情報に基づいた最良の決定を下すことができない可能性があります(統計の収集方法を決める要素としての時間とリソースの消費、古い統計が貧弱な問合わせ計画を生成する例、および古い統計情報を参照)。統計を再収集するための各種しきい値を設定し、不要な場合にはシステムが統計の再収集を行なわないようにできます。統計を再収集するためのしきい値の指定について詳しくは、<Teradata Vantage™ - SQLデータ定義言語 - 詳細トピック、B035-1184>の「COLLECT STATISTICS (最適化ルーチン形式)」を参照してください。
リクエスト内のインデックスが付けられている列についての統計が収集されていない場合、最適化ルーチンは、データのスナップショット サンプリングを作成し、その見積もりを使用して最適なデータ取得パスを推定します(動的AMPサンプリングを参照)。最適化ルーチンが開発する派生統計は、追加の統計を抽出するための基礎として、動的AMPサンプルを使用して開始されます。最適化ルーチンは、カーディナリティの見積もりを行なう際に、インデックスが付けられていない列の動的AMPサンプルを使用しないことに注意してください。
この動的AMPサンプルが列またはテーブルの集団統計に近似する程度は、テーブルのサイズに直接比例します。テーブルが大きければ大きいほど、サンプルは実際のグローバル デモグラフィックに近似するようになります。
最適化ルーチンのプロセス
以下は、最適化ルーチン処理ステージの簡略化されたリストです。
- 最適化ルーチンは、着信リクエスト パーセルを検査して、これから最適化するSQLテキストが、DMLリクエストかDDL/DCLリクエストかを判定します。
リクエスト パーセルのSQLリクエストのタイプ 最適化ルーチンの処理 DDLまたはDCL 最適化ルーチンは、特定のデータ ディクショナリ操作と置き換えたあとで、解析ツリーから元のリクエストを削除します。 DDLおよびDCLリクエストにはアクセス計画が必要ないため、最適化ルーチンは、そのリクエスト パーセルをディクショナリの書込みに関係する作業ステップや情報のロックなどに変換するだけです。
DML 最適化ルーチンは、アクセス計画、結合計画、および実行計画を生成します。 最適化ルーチンは、次に、完全なまたはサンプリングされた統計情報を使用して、どのアクセス パスまたは実行計画を採用するかを決定します。
統計キャッシュ内に列統計またはインデックス統計がない場合には、最適化ルーチンは動的AMPサンプリングを使用して、データの母集団統計を見積もります。
- 最適化ルーチンは、各ステップを順次(シリアル)に実行するのか、並列(パラレル)に実行するのか、また各ステップを単独のステップにするのか、共通の処理ステップにするのかを決定します。
- 解析ツリーは、最適化されたアクセス パス、結合計画および集約によってさらに肉付けされ、最適化ルーチンは、利用可能な派生統計と、その統計に含まれるコスト データに基づいて最良のパスを選択します。
- 最適化ルーチンは、デッドロックの発生する可能性を低くするためにテーブル レベルのロックを配置、組み合わせ、および再整理し、重複するロックがあれば削除します。
- 最後に、最適化ルーチンは、ホワイト ツリーとして知られる完全に最適化された構文解析ツリーを、さらに処理するために生成ルーチンに渡すか、またはEXPLAINリクエストを最適化している場合は、ホワイト ツリーの言葉による説明を生成します。この説明には、追加のスプール サイズ情報と、別途コストの見積もりは行なわれないコスト データが追加されます。このデータを分析したり、Teradata ViewPointで使用することができます。
問合わせ最適化ルーチンが実行しないタスク
- 最適化ルーチンが生成するアクセス計画、結合計画および集約計画は、間違いなく最良の計画であると保証すること。
問合わせ最適化ルーチンは、扱う対象の集団および環境デモグラフィックと、問合わせ最適化ルーチンが受け取る問合わせのコードの品質とに基づいて、常に最適の計画を作成し、その後にSQLリクエストに応答するように設定されている生成済みの計画から最適な計画を選択します。
どのクエリー最適化ルーチンも特定のSQLリクエストをサポート可能な最適なクエリー計画を作成すると考えるべきではありません。
選択された問合わせ計画は、最適化されていない意味解釈ルーチンのResTree' (Red Treeとも呼ばれる)を基盤としたものより適したものであると考えるべきです。
- 不完全な形式の問合わせを合理化して、同じ結果を返す意味上同等な完全な形式の問合わせと同じほど効果的に機能するようにすること。
クエリー最適化ルーチンは、提示されたリクエストのために、作成できる最も効果的な計画を作成します。とはいえ、意味上同等のクエリーでも実行時間が大きく異なる場合があります。これは、作成された元のSQLコードの質にも大きく依存しています。クエリー リライト(クエリー リライト、統計、および最適化を参照)の機能と最適化ルーチンが特定のユーザー作成クエリーの効率を向上させるには限界があります。
ステップの種類について
AMPステップ
AMPステップとは、リクエスト パーセルに対する応答についてのタスクを実行するために、1つ以上のAMPが処理する操作を記述するデータ構造のことです。あるリクエストのために組み合わされたAMPステップは、そのリクエストの計画の構成要素になります。
数種類のステップがありますが、最も重要なものはプラスチック ステップとコンクリート ステップです。 プラスチック ステップとコンクリート ステップの詳細については、生成ルーチンを参照してください。
並列ステップ
並列ステップとは、AMPによって同時に実行できる同じリクエスト パーセルからのステップ、または複数のAMPによって同時に実行できるリクエスト パーセル内の単一のステップのことです。並列ステップは、Teradataアーキテクチャに継承された並列性を利用します。各並列ステップには独立した実行パスがあり、他のステップと同時に実行されます。
最適化ルーチンは、タスクのどのステップを並列的に実行できるかを判定し、それらをグループにまとめます。最適化ルーチンによって可能な限り生成されるこれらの並列ステップによって、BYNETアーキテクチャを最大限に活用することができます。
最適化ルーチンによって指定される並列ステップはすべて、EXPLAIN機能によって明示的に報告されます。ディスパッチャには、実際、アクティブに並列実行できるステップの数についての制限があることに注意してください。また、AMPレベルでのチェックにより、前の並行ステップが完了するまで、次の並列ステップがブロックされる可能性があります。
さらに、ステップで、行が送信される他のステップを生成することがあります。例えば、再分散中です。送信ステップと生成された受信ステップは並行して実行され、メッセージ システムは送信側と受信側の間のパイプラインとして機能します。
共通ステップ
共通ステップとは、同じリクエスト パーセルまたはマクロからの複数のSQL文に共通の処理ステップのことです。このようなステップは、最適化ルーチンによって共通ステップとして認識され、組み合わせされます。
例えば、以下のような複文リクエスト パーセルを考えてみます。
SELECT employee_number, last_name, ‘Handling Calls’ FROM employee WHERE employee_number IN (SELECT employee_number FROM call_employee) ;SELECT employee_number, last_name, ‘Not Handling Calls’ FROM employee WHERE employee_number NOT IN (SELECT employee_number FROM call_employee);
最適化ルーチンは、以下のテーブルに示す共通ステップ アプローチによってこれらのリクエストを並列的に処理します。
ステップ | プロセス | 処理モード | ステップのタイプ |
---|---|---|---|
1 | ロック マネージャが両方のテーブル(employee_numberおよびcall_emp)をロックします。 | 順次 | 共通 |
2 | Teradata Databaseは、employee_numberテーブルの行をコピーして、再分散します。 システムは、テーブルcall_empの行をコピーして、再分散します。 |
並列 | 共通 |
3 | Teradata Databaseが結果をマージ結合します。 | 順次 | 単独 |
4 | Teradata Databaseが結果を排他マージ結合します。 | 順次 | 単独 |
5 | ロック マネージャがテーブル レベルのロックをemployee_numberとcall_empで解放します。 | 順次 | 単独 |
以下の図に示すように、最適化ルーチンは、パーセル用に並列ステップと共通ステップを生成します。
詳細情報
問合わせの最適化についての詳細は、クエリー リライト、統計、および最適化を参照してください。
Teradata Databaseによる結合リクエストの最適化方法の詳細については、結合計画と最適化および結合の最適化を参照してください。
最適化ルーチンのコンポーネントでもあるTeradata Index WizardおよびViewpoint統計マネージャの詳細については、<Teradata® Index Wizardユーザー ガイド、B035-2506>および<Teradata® Viewpointユーザー ガイド、B035-2206>の「統計マネージャ」を参照してください。