• 検索結果がありません。

効率の悪いアクセスパス(FULL SCAN)のチューニング例

ドキュメント内 HiRDB Version 10 パフォーマンスガイド (ページ 93-97)

4. 統合テストが終了したら,pdobils コマンドを実行して,SQL オブジェクト用バッファの統計情報を 取得します。統合テストを繰り返し実行する場合は,出力ファイル名を変更して,実行してください。

6.2  効率の悪いアクセスパス(FULL SCAN)のチューニング例

6.2.1 効率の悪いアクセスパス(FULL SCAN)のチューニング例の説明

インデクスの全範囲をサーチする FULL SCAN のアクセスパスを,インデクスのサーチ範囲を絞り込んだ アクセスパスに変更するチューニング例を説明します。

(1) 例題の概要

在庫管理表から,ある商品の店舗ごとの在庫数を検索します。

(a) 表およびインデクス定義

在庫管理表の構成と,この表に定義されたインデクスについて,次に示します。

図 6‒1 表およびインデクス定義

(b) SQL 文

実行する SQL 文を次に示します。

SELECT 店舗ID,在庫数 FROM 在庫管理表 WHERE 商品ID = ?

(c) データ件数とヒット件数

データ件数と SQL 文のヒット件数について,次に示します。

表 6‒2 データ件数とヒット件数

内容 件数

在庫管理表のデータ件数 約 1,000,000 件

SQL 文のヒット件数 約 100 件

(d) アクセスパス

この SQL 文のアクセスパスを出力すると,アクセスパス情報のサーチ条件の行に「FULL SCAN」と表示 されます。HiRDB SQL Tuning Advisor と UAP 統計レポートのアクセスパス出力結果を次に示します。

図 6‒2 HiRDB SQL Tuning Advisor の出力結果(チューニング前)

図 6‒3 UAP 統計レポートの出力結果(チューニング前)

(2) チューニングの考え方

FULL SCAN は効率の悪いアクセスパスのため,対策が必要です。FULL SCAN の対策方法は,「FULL

SCAN の対策」で説明しています。この内容に沿って対策してください。

(a) 要因の特定

まず,FULL SCAN になる要因を特定してください。例題の SQL 文は,次に示す理由から「インデクス の第1構成列に対する探索条件が指定されていない」ことが要因であることがわかります。

• HiRDB SQL Tuning Advisor でアクセスパスを出力した場合 次のガイダンスメッセージが出力されています。

• KFPX29604-I

• KFPX29985-I

• UAP 統計レポートでアクセスパスを出力した場合

「SearchCnd」が「RANGE」で行の末尾に「(FULL SCAN)」と表示されています。

[主キーとインデクスについて]

在庫管理表には,主キーとして店舗 ID 列,商品 ID 列が指定されています。主キーを指定した列には,

インデクスが定義されます。この例では複数の列を主キーに指定しているため,店舗 ID 列が第1構成 列,商品 ID 列が第 2 構成列である複数列インデクスが定義されます。この例の SQL 文では,インデ クスの第 1 構成列である店舗 ID 列に探索条件が指定されていません。このため,インデクスの全範囲 をサーチする「FULL SCAN」のアクセスパスになっています。

(b) 対策方法

第 1 構成列に対する探索条件が指定されていない場合の対策方法について,どの対策方法が採用できるか 検討してください。この例での検討結果を次に示します。

表 6‒3 第 1 構成列に対する探索条件が指定されていない場合の対策方法

対策方法 説明 検討結果

SQL 文の変更 第 1 構成列に対する探索条件の指定が

漏れている場合は,追加してください。

【不採用】

例題の SQL 文は,第 1 構成列 である店舗 ID 列の探索条件が 漏れている訳ではないため,

SQL 文の変更はできません。

インデクス構成列順序の変更 =条件など最も絞り込める条件を指定

している列を第 1 構成列にできない か,インデクスの構成列の順序を見直 してください。

【不採用】

例題の SQL 文以外に,店舗 ID 列だけに探索条件を指定した SQL 文を実行するため,インデ クス構成列の順序を変更するこ とはできません。

新しいインデクスの追加 =条件など最も絞り込める条件を指定

している列が第 1 構成列である新しい インデクスの追加を検討してください。

【採用】

在庫管理表には主キー以外にイ ンデクスは定義されていないた め,新しいインデクスを追加し ても,インデクスの数は問題あ りません。このため,商品 ID 列に単一列インデクスを定義す ることで対策できます。

この例では,新しいインデクスを追加して対策します。

(3) チューニング結果

(a) 表およびインデクス定義

商品 ID を第 1 構成列とするインデクス「在庫管理表 IDX1」を追加してください。変更後のインデクス定 義について,次に示します。

図 6‒4 表およびインデクス定義

(b) SQL 文

変更しません。

(c) アクセスパス

アクセスパスを出力して,新しいインデクス「在庫管理表 IDX1」を使用した INDEX SCAN に変更され たことを確認してください。

図 6‒5 HiRDB SQL Tuning Advisor の出力結果(チューニング後)

図 6‒6 UAP 統計レポートの出力結果(チューニング後)

(4) まとめ

このチューニング例のポイントを次に示します。

[ポイント]

• SQL 文の探索条件の内容を考慮して,主キー以外のインデクスも検討してください。

• 複数列インデクスでは,構成列の順序を意識してください。詳細は,マニュアル「HiRDB システ ム導入・設計ガイド」の「インデクス構成列の検討」を参照してください。

ドキュメント内 HiRDB Version 10 パフォーマンスガイド (ページ 93-97)