Hitachi

ノンストップデータベース HiRDB Version 9 パフォーマンスガイド


6.4.1 中間結果情報(SCAN)の件数が多い場合のチューニング例の説明

データを絞り込めるように,使用するインデクスを変更するチューニング例を説明します。

〈この項の構成〉

(1) 例題の概要

案件管理表から,ある月に登録された特定の種別の案件のうち,完了している案件を検索します。

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

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

図6‒13 表およびインデクス定義と各列の値

[図データ]

[各列の値の説明]

  • 完了フラグ列は,0と1の2種類の値しか格納されません。

  • 案件ID列は,案件種別コード,案件日付,通番の値を組み合わせた値です。

(b) SQL文

実行するSQL文を次に示します。BETWEEN述語の後の?パラメタには,検索したい月の案件IDの最小値と最大値を指定します。例えば,案件種別コード0123で2015年5月に登録された案件を検索する場合は,'0123201505010001'と'0123201505319999'になります。

SELECT * FROM 案件管理表
 WHERE 案件ID BETWEEN ? AND ?
 AND 完了フラグ = 1

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

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

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

内容

件数

案件管理表のデータ件数

約1,000,000件

完了フラグの値が1である件数

約700,000件

SQL文のヒット件数

約50件

(d) アクセスパスと中間結果情報

このSQL文のアクセスパスを出力すると,アクセスパス情報の検索方法は「INDEX SCAN」となり,問題ありません。しかし,中間結果情報の実表検索処理情報を確認すると,インデクスで絞り込んだ行数(Search)と取り出した行数(Row Count)に開きがあります。UAP統計レポートのアクセスパス情報と実表検索処理情報の出力結果を次に示します。

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

[図データ]

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

検索に使用しているインデクス(案件管理表IDX1)では,取り出すデータを絞り込めていないため,対策が必要です。インデクスで絞り込めていない場合の対策方法は,「実表検索処理情報(SCAN)のRow CountとSearch」で説明しています。この内容に沿って対策してください。

この例では,アクセスパスで「RowCnd」に表示されている案件ID列に主キーが定義されています。したがって,使用するインデクスを変更します。SQL文にSQL最適化指定(WITH INDEX)で主キーを指定します。

[図データ][インデクスを定義する列の値の種類について]

フラグのような種類の少ない値を格納する列に定義したインデクスは,データを絞り込むことができません。このような列にはインデクスを定義しないで,別の絞り込める列に定義したインデクスを使用するようにしてください。

(3) チューニング結果

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

使用するインデクスを変更するチューニングのため,表およびインデクス定義の変更はありません。ただし,完了フラグ列に定義したインデクスは,絞り込めないため,削除してください。

(b) SQL文

SQL最適化指定(WITH INDEX)で使用するインデクスに主キーを指定するSQL文に変更してください。下線部分が変更した個所です。

SELECT * FROM 案件管理表 WITH INDEX (PRIMARY KEY)
 WHERE 案件ID BETWEEN ? AND ? 
 AND 完了フラグ = 1;

(c) アクセスパスと中間結果情報

アクセスパスを出力して,使用するインデクスが変更になり,インデクスで絞り込めていることを確認してください。

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

[図データ]

(4) まとめ

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

[図データ][ポイント]

フラグのような種類の少ない値を格納する列にはインデクスを定義しないでください。詳細は,マニュアル「HiRDB Version 9 システム導入・設計ガイド」の「インデクス作成に適さない列」を参照してください。