Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

10.3. クエリープラン

フェデレーションされたクエリープランナーを使用して情報を統合する際に、クエリー計画を表示して情報にアクセスおよび処理される方法をさらに理解し、問題のトラブルシューティングを行うと便利です。

クエリー計画（実行または処理計画としても知られる）は、ユーザーまたはアプリケーションが送信するコマンドを実行するためにクエリーエンジンによって作成される一連の命令です。クエリー計画の目的は、可能な限り効率的な方法でユーザーのクエリーを実行することです。

クエリー計画の取得

コマンドの実行時には、クエリー計画を取得できます。以下の SQL オプションを使用できます。

SET SHOWPLAN [ON|DEBUG]:処理計画またはプランおよび完全なプランナーのデバッグログを返します。詳細は、『Client Developer's Guide』の「 Query planner and SET statement 」を参照してください。上記のオプションを使用すると、org.teiid.jdbc.TeiidStatement インターフェースにキャストするか、または SHOW PLAN ステートメントを使用して、クエリー計画が Statement オブジェクトから利用できます。詳細は、『Client Developer's Guide』の「 SHOW Statement 」を参照してください。または、EXPLAIN ステートメントを使用できます。詳細は、「 Explain statement 」を参照してください。

Data Virtualization 拡張機能を使用したクエリー計画の取得

statement.execute("set showplan on");
ResultSet rs = statement.executeQuery("select ...");
Data VirtualizationStatement tstatement = statement.unwrap(TeiidStatement.class);
PlanNode queryPlan = tstatement.getPlanDescription();
System.out.println(queryPlan);

ステートメントを使用したクエリー計画の取得

statement.execute("set showplan on");
ResultSet rs = statement.executeQuery("select ...");
...
ResultSet planRs = statement.executeQuery("show plan");
planRs.next();
System.out.println(planRs.getString("PLAN_XML"));

explain を使用したクエリー計画の取得

ResultSet rs = statement.executeQuery("explain select ...");
System.out.println(rs.getString("QUERY PLAN"));

クエリー計画は、複数の Data Virtualization のツールで自動的に利用可能になります。

クエリー計画の分析

クエリー計画を取得したら、以下の項目について確認できます。

  • source pushdown xmvn-gitops 各ソースにプッシュされたクエリーの部分

    • 特にインデックスに対して述語がプッシュされていることを確認します。

  • joins-1.6.0--で合成された結合は、非常にコストのかかる可能性があります。

    • join orderingfaillock-gitopsTypical impacting by costing
    • 条件タイプの不一致に参加します。
    • join アルゴリズムを使用して、マージやネストされたループの強化などを行いました。
  • 依存する参加などのフェデレーションされた最適化があること。

  • ヒントに、必要な影響があることを確認します。ヒントの使用に関する詳細は、以下の追加リソースを参照してください。

処理計画から前述のリスト内のすべての情報を確認できます。通常、最終処理計画のテキスト形式の分析に関心があります。デバッグまたはサポートに対して特定の決定が行われる理由を理解するには、中間計画ステップを含む完全なデバッグログと、特定のプッシュダウン決定が行われる理由へのアノテーションを取得します。

クエリー計画は、ツリー構造で整理されたノードのセットで構成されます。手順を実行している場合、クエリー計画全体には、周りの手順の実行に関連する追加情報が含まれます。

手順のコンテキストでは、子ノードの順序は実行の順序を意味します。ほとんどの場合、子ノードは並行しても任意の順序で実行できます。依存結合などの特定の最適化では、結合の子が順次実行されます。

リレーショナルデータベース計画

リレーショナルデータベースは、論理関係操作のビルディングブロックを表すノードで構成される処理計画を表します。リレーショナルデータベース処理計画には、追加の操作とオプティマイザーで選択した実行の詳細が含まれるという点で、論理デバッグのリレーショナルデータベースとは異なります。

リレーショナルデータベースクエリー計画のノードは以下のとおりです。

  • accessで source にアクセスします。ソースクエリーは、ソースに関連付けられた接続ファクトリーに送信されます。（依存する結合の場合、このノードは Dependent Access と呼ばれます。）
  • 依存する手順は、複数の入力値のセットを使用してソースのストアドプロシージャーにアクセスします。
  • バッチの更新で、更新のセットをバッチとして処理します。
  • projectgitops-で、ノードから返された列をDefinines にします。返されたレコード数は変更しません。
  • プロジェクトを通常のプロジェクトと同様ですが、ターゲットテーブルに行を出力します。
  • プロジェクトにプランの実行で完了し、ソースクエリーではなくプランを実行します。通常、クエリー式を使用してビューに挿入するときに作成されます。
  • window function project336-TEMPLATESLike は通常のプロジェクトで使用されますが、ウィンドウ機能が含まれます。
  • pidgin-TEMPLATESSelect は、基準評価フィルターノード(WHERE / HAVING)です。
  • jointypes - join タイプ、結合基準、結合ストラテジー（merge または nested loop）に参加します。
  • このノードのプロパティーをすべて選択せずに、その子から行を渡します。トランザクションまたはソースクエリーの同時実行が許可されているかどうかなど、他の要素によっては、すべての結合子が並行して実行されるわけではありません。
  • ソートする列を並べ替える - ソートする列、各列のソート方向、重複を削除するかどうかを指定します。
  • dup removegitops-gitopsRemoves の重複行。処理はツリー構造を使用して重複を検出し、結果を IO 操作のコストが効率的にストリーミングできるようにします。
  • 一連の行のセットをグループにグループ化し、集約関数を評価します。
  • 行が生成されない null rhncfg-で、AnbileA ノード。通常は、基準が常に false（および下のツリー）である Select ノードを置き換えます。このノードのプロパティーはありません。
  • プランの実行 - 別のサブプランを実行します。通常、サブ計画は関係しないプランです。
  • 依存する手順の実行 - 複数の入力値セットを使用してサブプランを実行します。
  • 制限制限 - 指定した数行数を書き込んでから、処理を停止します。また、存在する場合はオフセットも処理します。
  • XML table PROVISIONING-gitopsEvaluates XMLTABLE.デバッグ計画には、最適化に関して XQuery/XPath に関する詳細情報が含まれます。詳細は「 XQuery optimization 」を参照してください。
  • テキストテーブル - Evaluates TEXTTABLE
  • array table - Evaluates ARRAYTABLE
  • Object table - Evaluates OBJECTTABLE

ノードの統計

すべてのノードには、出力される統計セットがあります。これらは、ノードを通過するデータの量を決定するために使用できます。プロセッサープランを実行する前には、ノードの統計は含まれません。また、統計はプランの処理時に更新されるので、通常はすべての行がクライアントによって処理された後に最終的な統計が必要です。

Expand
統計説明ユニット

ノード出力行

ノードからの出力のレコード数。

count

ノードの次のバッチプロセス時間

このノードの時間処理。

millisec

ノードの累積次のバッチプロセス時間

このノード + 子ノードにおける時間処理。

millisec

ノードの累積プロセス時間

処理の開始から終了までの経過時間。

millisec

ノードの次のバッチ呼び出し

ノードが処理のために呼び出された回数。

count

ノードブロック

このノードまたは子によってブロックされた例外がスローされた回数。

count

ノードの統計以外にも、一部のノードの表示コストにより、ノードで計算される予測が予測されます。

Expand
Cost Estimates説明ユニット

推定ノードのカーディナリティー

ノードから出力されるレコードの推定数。不明な場合は -1。

count

ルートノードが追加情報を表示します。

Expand
最上位の統計説明ユニット

Data Bytes Sent

クライアントに送信されるシリアライズされたデータ結果（行と緩やかの値）のサイズ。

bytes

プロセッサープランの読み取り

クエリープロセッサープランは、プレーンテキストまたは XML 形式で取得できます。通常、プランのテキスト形式は読みやすくなりますが、XML 形式はツールによって処理が簡単です。ツリー構造は詳細にネストできるため、ツールを使ってプランを調べる必要があります。

ツリーのリーフからルートへのデータフロー。手順実行のサブプランはインラインで示され、インデントが異なります。pm1 .g1.e1=pm1.g3.e1、pm1.g2.e2、pm1.g3.e3 のユーザークエリーが pm1.g1 の内部参加（pm1.g2 left outer は pm1.g2.e1=pm1.g3.e1）の pm1.g1.e1=pm1.g3.e1 で、結合をプッシュしないプロセッサープランのテキストは次のようになります。 

ProjectNode
  + Output Columns:
    0: e1 (string)
    1: e2 (integer)
    2: e3 (boolean)
  + Cost Estimates:Estimated Node Cardinality: -1.0
  + Child 0:
    JoinNode
      + Output Columns:
        0: e1 (string)
        1: e2 (integer)
        2: e3 (boolean)
      + Cost Estimates:Estimated Node Cardinality: -1.0
      + Child 0:
        JoinNode
          + Output Columns:
            0: e1 (string)
            1: e1 (string)
            2: e3 (boolean)
          + Cost Estimates:Estimated Node Cardinality: -1.0
          + Child 0:
            AccessNode
              + Output Columns:e1 (string)
              + Cost Estimates:Estimated Node Cardinality: -1.0
              + Query:SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0
              + Model Name:pm1
          + Child 1:
            AccessNode
              + Output Columns:
                0: e1 (string)
                1: e3 (boolean)
              + Cost Estimates:Estimated Node Cardinality: -1.0
              + Query:SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0 ORDER BY c_0
              + Model Name:pm1
          + Join Strategy:MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)
          + Join Type:INNER JOIN
          + Join Criteria:pm1.g1.e1=pm1.g3.e1
      + Child 1:
        AccessNode
          + Output Columns:
            0: e1 (string)
            1: e2 (integer)
          + Cost Estimates:Estimated Node Cardinality: -1.0
          + Query:SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0 ORDER BY c_0
          + Model Name:pm1
      + Join Strategy:ENHANCED SORT JOIN (SORT/ALREADY_SORTED)
      + Join Type:INNER JOIN
      + Join Criteria:pm1.g3.e1=pm1.g2.e1
  + Select Columns:
    0: pm1.g1.e1
    1: pm1.g2.e2
    2: pm1.g3.e3

ネストされた結合ノードはマージ結合を使用しており、各サイドのソースクエリーが結合の予想される順序を生成することを予想することに注意してください。親結合は強化されたソート結合で、受信行に基づいてソートの実行を遅らせることができます。null 内部値がクエリー結果に存在しないため、ユーザークエリーからの外部参加は内部参加に変更されています。

前述のプランは、以下の例のように XML 形式で表現することもできます。 

<?xml version="1.0" encoding="UTF-8"?>
<node name="ProjectNode">
    <property name="Output Columns">
        <value>e1 (string)</value>
        <value>e2 (integer)</value>
        <value>e3 (boolean)</value>
    </property>
    <property name="Cost Estimates">
        <value>Estimated Node Cardinality: -1.0</value>
    </property>
    <property name="Child 0">
        <node name="JoinNode">
            <property name="Output Columns">
                <value>e1 (string)</value>
                <value>e2 (integer)</value>
                <value>e3 (boolean)</value>
            </property>
            <property name="Cost Estimates">
                <value>Estimated Node Cardinality: -1.0</value>
            </property>
            <property name="Child 0">
                <node name="JoinNode">
                    <property name="Output Columns">
                        <value>e1 (string)</value>
                        <value>e1 (string)</value>
                        <value>e3 (boolean)</value>
                    </property>
                    <property name="Cost Estimates">
                        <value>Estimated Node Cardinality: -1.0</value>
                    </property>
                    <property name="Child 0">
                        <node name="AccessNode">
                            <property name="Output Columns">
                                <value>e1 (string)</value>
                            </property>
                            <property name="Cost Estimates">
                                <value>Estimated Node Cardinality: -1.0</value>
                            </property>
                            <property name="Query">
                                <value>SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0</value>
                            </property>
                            <property name="Model Name">
                                <value>pm1</value>
                            </property>
                        </node>
                    </property>
                    <property name="Child 1">
                        <node name="AccessNode">
                            <property name="Output Columns">
                                <value>e1 (string)</value>
                                <value>e3 (boolean)</value>
                            </property>
                            <property name="Cost Estimates">
                                <value>Estimated Node Cardinality: -1.0</value>
                            </property>
                            <property name="Query">
                                <value>SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0
                                    ORDER BY c_0</value>
                            </property>
                            <property name="Model Name">
                                <value>pm1</value>
                            </property>
                        </node>
                    </property>
                    <property name="Join Strategy">
                        <value>MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)</value>
                    </property>
                    <property name="Join Type">
                        <value>INNER JOIN</value>
                    </property>
                    <property name="Join Criteria">
                        <value>pm1.g1.e1=pm1.g3.e1</value>
                    </property>
                </node>
            </property>
            <property name="Child 1">
                <node name="AccessNode">
                    <property name="Output Columns">
                        <value>e1 (string)</value>
                        <value>e2 (integer)</value>
                    </property>
                    <property name="Cost Estimates">
                        <value>Estimated Node Cardinality: -1.0</value>
                    </property>
                    <property name="Query">
                        <value>SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0
                            ORDER BY c_0</value>
                    </property>
                    <property name="Model Name">
                        <value>pm1</value>
                    </property>
                </node>
            </property>
            <property name="Join Strategy">
                <value>ENHANCED SORT JOIN (SORT/ALREADY_SORTED)</value>
            </property>
            <property name="Join Type">
                <value>INNER JOIN</value>
            </property>
            <property name="Join Criteria">
                <value>pm1.g3.e1=pm1.g2.e1</value>
            </property>
        </node>
    </property>
    <property name="Select Columns">
        <value>pm1.g1.e1</value>
        <value>pm1.g2.e2</value>
        <value>pm1.g3.e3</value>
    </property>
</node>

各プランのフォームに同じ情報が表示されます。場合によっては、デバッグ計画の最終プロセッサープランの簡略化された形式に従うのが簡単になります。以下の出力は、デバッグログが前述の XML 例のプランを表している方法を示しています。 

OPTIMIZATION COMPLETE:
PROCESSOR PLAN:
ProjectNode(0) output=[pm1.g1.e1, pm1.g2.e2, pm1.g3.e3] [pm1.g1.e1, pm1.g2.e2, pm1.g3.e3]
  JoinNode(1) [ENHANCED SORT JOIN (SORT/ALREADY_SORTED)] [INNER JOIN] criteria=[pm1.g3.e1=pm1.g2.e1] output=[pm1.g1.e1, pm1.g2.e2, pm1.g3.e3]
    JoinNode(2) [MERGE JOIN (ALREADY_SORTED/ALREADY_SORTED)] [INNER JOIN] criteria=[pm1.g1.e1=pm1.g3.e1] output=[pm1.g3.e1, pm1.g1.e1, pm1.g3.e3]
      AccessNode(3) output=[pm1.g1.e1] SELECT g_0.e1 AS c_0 FROM pm1.g1 AS g_0 ORDER BY c_0
      AccessNode(4) output=[pm1.g3.e1, pm1.g3.e3] SELECT g_0.e1 AS c_0, g_0.e3 AS c_1 FROM pm1.g3 AS g_0 ORDER BY c_0
    AccessNode(5) output=[pm1.g2.e1, pm1.g2.e2] SELECT g_0.e1 AS c_0, g_0.e2 AS c_1 FROM pm1.g2 AS g_0 ORDER BY c_0

共通

  • Output columns: このノードによって返されるタプルを構成する列。
  • 送信されたデータバイト - メッセージングオーバーヘッドを含まないデータバイトの数がこのクエリーによって送信されました。
  • プランニング時間： クエリーの計画に費やした時間（ミリ秒単位）。

リレーショナル

  • リレーショナルノード ID336-TEMPLATES は、デバッグログ Node(id)に表示されるノード ID と一致します。
  • 基準 2: フィルタリングに使用するブール式です。
  • Projection を定義する columns xmvn-gitopshe 列を選択します。
  • グループ化に使用する列のグルーピング - グループ化に使用する列。
  • マッピングのグルーピングにより、集約およびグルーピング列の内部名から式フォームへのマッピングが表示されます。
  • querygitops-gitopsThe source query.
  • モデル名で、モデル名を使用しない場合は、このモデル名が必要です。
  • 同じソース結果を共有する ID Warehouse を共有すると、同じ共有 ID が設定されます。
  • 依存結合結合が使用されている場合、依存する join が使用されています。
  • 参加ストラテジーにジョインストラテジー（Nested Loop、Sort Merge、Enhanced Sort など）に参加します。
  • 参加するタイプにジョインするタイプ（左の参加、Inner Join、Cross Join）
  • 参加する条件(join predicates)に参加します。
  • 実行プランでネストされた実行計画です。
  • 挿入ターゲットにターゲットを使用。
  • 挿入が upsert の場合は Upsert-1.6.1+If を挿入します。
  • 並び替え列で、ソート用の列を並び替えます。
  • 並べ替えモードにソートすると、ソートも、個別の削除のように別の機能を実行します。
  • ロールアップオプションにより、グループに rollup オプションがあります。
  • statisticsfaillock-gitopsThe processing statistics.
  • コスト予測 - 依存する結合コスト予測を含むコスト/カーディナリティー予測。
  • 行のオフセット式に、行のオフセット式があります。
  • 行の上限 - 行制限式。
  • with 節で、with 節を使用します。
  • ウィンドウ関数で計算されるウィンドウ関数。
  • テーブル関数（XMLTABLE、OBJECTTABLE、TEXTTABLE など）
  • streamingで XMLTABLE がストリーム処理を使用していること。

手順

  • 式
  • 結果セット
  • program
  • 変数
  • 次に、
  • その他

その他のプラン

手順実行（トリガーを含む）は、リレーショナルデータベースを含む中間および最終計画のフォームを使用します。通常、XML/手順計画の構造は論理フォームに密接にマッチします。パフォーマンスの問題を分析する際に関連するネストされたリレーショナルデータベースプランです。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る