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

[目次][索引][前へ][次へ]

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

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

<この節の構成>
(1) 例題の概要
(2) チューニングの考え方
(3) チューニング結果
(4) まとめ

(1) 例題の概要

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

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

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

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

[図データ]

[各列の値の説明]

(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 システム導入・設計ガイド」の「インデクス作成に適さない列」を参照してください。