性能問題について

質問

set autotrace on で実行計画を見てみたのですが、
以下のテーブルAが全走査していました。
----------------------------------------------
TABLE ACCESS (FULL) OF 'テーブルA'
TABLE ACCESS (BY INDEX ROWID) OF 'テーブルB'
INDEX (UNIQUE SCAN) OF 'M_KAIINP1' (UNIQUE)
----------------------------------------------
そこでオプティマイザにヒントを与えました。
-----------------------------------------------
select /*+ INDEX (テーブルA M_LINEP1) */ 項目 from ～
-----------------------------------------------
すると結果が以下のようになりました。
実行計画
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2057 Card=27928 Byte
s=5390104)

1 0 MERGE JOIN (Cost=2057 Card=27928 Bytes=5390104)
2 1 INDEX (FULL SCAN) OF 'M_LINEP1' (UNIQUE) (Cost=26 Card=4
57735 Bytes=11901110)

3 1 SORT (JOIN) (Cost=2031 Card=27928 Bytes=4663976)
4 3 TABLE ACCESS (FULL) OF 'テーブルB' (Cost=703 Card=27928
Bytes=4663976)
----------------------------------------------------------
性能は格段に速くなったのですが、なんで速くなったのか原因がいまいちわかりません。
テーブルAとテーブルBはほぼ同じ件数（53万件程度）です。
上記を見るとテーブルAにインデックスがつけられ、テーブルBはフルで見るように変更になったと思うのですがそれだと速くなる理由がわからなくて・・・。
どなたかアドバイスお願いします。

回答No.1

entree · ベストアンサー

SQL文もテーブル定義も記述されていないので詳しいことは言えませんが、ヒント設定前はルールベースでネステッドループ結合がされていますが、ヒント設定後はコストベースとなり、ソートマージ結合が行われているようです。
ソートマージ結合は、両テーブルの内容をソートして、その結果をマージする結合方法ですが、幸いテーブルＡは実表を参照しなくてもよいようなSQLになっているようで、既にソートされているインデックスが利用され、実際のところテーブルＢだけがソートの対象になるため速くなっているものと考えられます。

ただし、十分なメモリを搭載しているのであれば、ハッシュ結合の方が速い可能性があります。