3.4.1　TABLE SCANの対策

(1)　TABLE SCANとは

TABLE SCANは，探索条件の内容に関わらず，検索対象表の全行をシーケンシャルにアクセスする方法のため，処理効率が悪いです。

図3‒8　TABLE SCANの処理方式

［こんなときは］

次の場合は，TABLE SCANのままでも問題ありません。

• 全件抽出を目的とする場合

• 表に格納する件数が極端に少ない場合

  採番目的の表など格納件数が1件の表が該当します。

ページの先頭へ

(2)　確認方法

TABLE SCANの確認方法を次に示します。

• HiRDB SQL Tuning Advisorの場合

  アクセスパス情報の「検索方法」に「TABLE SCAN」と表示されます。TABLE SCANの出力例を次に示します。

  図3‒9　HiRDB SQL Tuning Advisorの出力例（TABLE SCAN）

• UAP統計レポートの場合

  アクセスパス情報の「Scan Type」に「TABLE SCAN」と表示されます。

  TABLE SCANの出力例を次に示します。

  図3‒10　UAP統計レポートの出力例（TABLE SCAN）

ページの先頭へ

(3)　対策方法

探索条件に指定した列にインデクスが定義されていないため，TABLE SCANになっています。インデクスを追加して，インデクスを使用した検索方法（INDEX SCANまたはKEY SCAN）に変更してください。

［ポイント］

次の個所に表示された列にインデクスを定義することで，インデクスを使用した検索方法に変更できます。

• HiRDB SQL Tuning Advisorの場合

  「TABLE SCAN」の直前にある「ﾛｰ条件」または「If Then条件」に表示された列

  図3‒11　HiRDB SQL Tuning Advisorの出力例

• UAP統計レポートの場合

  「TABLE SCAN」の直下にある「RowCnd」または「IfThenCnd」に表示された列

  図3‒12　UAP統計レポートの出力例

［こんなときは］

「ﾛｰ条件（RowCnd）」または「If Then条件（IfThenCnd）」に表示された列にインデクスを定義しているにも関わらず，SQL文の作り方によっては，TABLE SCANになってしまうケースもあります。この要因について，次に示します。

1. インデクスを利用できない探索条件をOR論理演算している場合

2. NOT演算子（＜＞，^＝，!＝）で比較している場合

それぞれの要因について，対策方法を次に説明します。

［項番1の対策方法］

インデクスを利用できる探索条件がある場合でも，インデクスを利用できない探索条件^※をOR論理演算していると，TABLE SCANになります。この場合は，探索条件に指定した列が第1構成列であるインデクスを追加して，すべての探索条件でインデクスが利用できるようにします。これによって，複数インデクス利用（OR PLURAL INDEXES SCANまたはAND PLURAL INDEXES SCAN）に変更できます。

次に対策方法の例を示します。

［例題］

• インデクス定義列：C1

• SQL文：SELECT * FROM T1 WHERE C1=? OR C2=?

  下線はインデクスに含まれない列に対する探索条件のため，インデクスは利用できません。

［対策方法］

C2が第1構成列であるインデクスを追加します。

注※

次のSQL文の下線部分のように，表にアクセスしない探索条件もインデクスを利用できません。この場合，表にアクセスしない探索条件はアプリケーション側で判定し，SQL文からこの探索条件を外すことができないか，検討してください。

SELECT * FROM T1 WHERE C1=? OR 1=?

［項番2の対策方法］

NOT演算子（＜＞，^＝，!＝）で比較している場合は，NOT演算子は使用しないように探索条件の指定方法を変更してください。

ページの先頭へ