Click here to view and discuss this page in DocCommentXchange. In the future, you will be sent there automatically.

SQL Anywhere 11.0.1 (日本語) » SQL Anywhere サーバ - SQL の使用法 » クエリ処理 » クエリの最適化と実行 » 実行プランの解釈 » グラフィカルなプランの解釈

 

統計情報付きのグラフィカルなプランによるパフォーマンス分析

統計情報付きのグラフィカルなプランを使用して、データベースのパフォーマンス上の問題を識別できます。統計情報付きのグラフィカルなプランのフィールドの詳細については、[ノード統計] フィールドの説明[オプティマイザ統計] フィールドの説明を参照してください。

クエリの実行上の問題の識別

クエリの実行に影響するデータベース・オプションやその他のグローバルな設定は、ルート演算子ノードについてのみ表示できます。

選択性のパフォーマンスの確認

述部の選択性 (条件式) は、条件を満たすローの割合のことです。推定される述部の選択性が提供する情報に基づいて、オプティマイザはコストの推定を行います。オプティマイザの正常な処理には、正確な選択性推定が不可欠です。たとえば、オプティマイザが述部の選択性が高い (5% の選択性など) と誤って推定しても、実際には述部の選択性がかなり低い (50% など) 場合は、パフォーマンスが低下することがあります。選択性推定は正確ではない場合がありますが、極端に大きな誤差は問題がある可能性を示しています。

クエリの重要な部分の選択性情報が不正確であると判断した場合、CREATE STATISTICS を使用してカラムの新しい統計値セットを生成できます。まれに、明示的な選択性推定を指定したい場合があります。ただし、この方法では、後で統計を更新するときに問題が発生する可能性があります。

クエリがバイパス・クエリだと判断された場合、選択性統計値は表示されません。バイパス・クエリの詳細については、オプティマイザの仕組み明示的な選択性推定を参照してください。

次のような場合に不適切な選択性の兆候が見られます。

  • RowsReturned の実際値と推定値   RowsReturned は結果セット内のロー数です。RowsReturned 統計値は、ツリーの先頭にあるルート・ノードのテーブル内に表示されます。推定ロー・カウントが実際のロー・カウントと大きく異なる場合は、このノードまたはサブツリーに接続された述部の選択性が正しくない可能性があります。

  • 述部選択性の実際値と推定値   述部」というサブヘッダを検索して、述部の選択性を確認します。述部情報の解釈については、グラフィカル・プラン内の選択性の表示を参照してください。

    ヒストグラムが存在しないベース・カラムに対する述部がある場合は、ヒストグラムを作成するために CREATE STATISTICS 文を実行すると問題を修正できる場合があります。CREATE STATISTICS 文を参照してください。

    選択性の誤差に問題が残る場合は、クエリ・テキストに述部とともにユーザ推定選択性を指定することも可能です。

  • 推定ソース   選択性推定のソースも、[統計情報] ウィンドウ枠の述部サブヘッダの下にリストされています。

    述部選択性推定のソースが Guess の場合、オプティマイザには述部のフィルタリングの特性の判断に使用できる情報がないため、ヒストグラムがないなどの問題を示す可能性があります。推定ソースが Index で、選択性推定が正しくない場合は、インデックスが偏っていることが問題である可能性があります。REORGANIZE TABLE 文を使用してインデックスの断片化を解除すると改善できる場合があります。REORGANIZE TABLE 文を参照してください。

キャッシュのパフォーマンスの確認

キャッシュの読み込み数 ([CacheRead] フィールド) とヒット数 ([CacheHits] フィールド) が同じである場合は、この SQL 文のために処理されるすべてのオブジェクトがキャッシュに保持されています。キャッシュの読み込み数がヒット数よりも多い場合は、テーブルまたはインデックス・ページがサーバのキャッシュに存在しないため、データベース・サーバがこれらをディスクから読み込んでいることを示します。これは、ハッシュ・ジョインなどの場合に予想されます。ネスト・ループ・ジョインなどの場合、キャッシュ・ヒット率が低いときは、クエリを効率的に実行するためのキャッシュ (バッファ・プール) の不足を示している可能性があります。この場合、サーバのキャッシュ・サイズを増やすと改善できることがあります。

キャッシュ管理の詳細については、キャッシュ・サイズの拡大を参照してください。

無効なインデックスの識別

クエリ実行プランからは、インデックスがパフォーマンスの向上に役立っているかどうかが不明な場合がよくあります。SQL Anywhere で使用されているスキャンベースのアルゴリズムの中には、インデックスを使用せずに多くのクエリに対して最高のパフォーマンスを提供するものもあります。

インデックスとパフォーマンスの詳細については、インデックスの有効な使用インデックス・コンサルタントを参照してください。

データの断片化の問題の識別

Runtime および FirstRowRunTime の実際値と推定値は、ルート・ノード統計値で提供されます。ノードに RunTime が存在する場合、[サブツリー統計] セクションにはこの値だけが表示されます。

RunTime の解釈は、表示される統計セクションによって異なります。[ノード統計] の場合、RunTime はこのノードだけを実行している間に、対応する演算子が費やした累積時間です。[サブツリー統計] の場合、RunTime はこのノードの直下にある演算子のサブツリー全体に対して費やされた合計実行時間を表します。したがって、ほとんどの演算子では RunTimeFirstRowRunTime は独立した測定値で、個別に分析する必要があります。

FirstRowRunTime は、このノードの中間結果の最初のローを作成するために要した時間です。

テーブル・スキャンまたはインデックス・スキャンで、ノードの RunTime が予想よりも大きい場合、REORGANIZE TABLE 文を実行するとパフォーマンスを向上できることがあります。sa_table_fragmentation() システム・プロシージャと sa_index_density() システム・プロシージャを使用して、テーブルまたはインデックスが断片化されているかどうかを判断できます。

詳細については、REORGANIZE TABLE 文テーブルの断片化削減を参照してください。

プランに使用されるコード・ワードの詳細については、実行プランの省略形を参照してください。