インデックスに関する検証 その4

投稿日: 2000年7月05日

<インデックスに関する検証 その4> ペンネーム つけまい

— インデックス利用の落とし穴
レンジ検索で全件検索よりも性能ダウン —

前回、1万件のテーブルに対して、1~5000件目(半分)までのレンジ検索を行っ
た結果、インデックスに対して45回のI/Oが発生した。

この結果を、TREEDUMP機能を用いて確認してみよう。

TREEDUMPを取得するには、まずインデックスのOBJECT_IDを知る必要がある。
OBJECT_IDを知るには、以下のSELECT文を用いる。

SELECT OBJECT_NAME,
OBJECT_ID
>FROM USER_OBJECTS WHERE OBJECT_TYPE = 'INDEX' ;
OBJECT_NAME  OBJECT_ID
-----------  ---------
ID_EMP            3461
PK_DEPT           1924
PK_EMP            1926
TEST01            3539

次に、OBJECT_IDを指定してTREEDUMPを取得する。

ALTER SESSION SET EVENTS
'IMMEDIATE TRACE NAME TREEDUMP LEVEL 3539' ;
└→TEST01に割り振られたOBJECT_ID

なお、TREEDUMPの出力先は、初期化パラメータ user_dump_dest に指定された
ディレクトリである(ora_xxxx.trcというファイルの最新のもの)。

●TREEDUMP

----- begin tree dump
branch: 0x5800003 92274691 (0: nrow: 87, level: 1)  (1)
leaf: 0x2000004 33554436 (-1: nrow: 116)  ↑
leaf: 0x2000005 33554437 (0: nrow: 116)   |
leaf: 0x2000006 33554438 (1: nrow: 116)   |
leaf: 0x2000007 33554439 (2: nrow: 116)   |
leaf: 0x2000008 33554440 (3: nrow: 116)   |
:                      |
:                      |
leaf: 0x2000018 33554456 (19: nrow: 116)  |
leaf: 0x2000019 33554457 (20: nrow: 116)  |
leaf: 0x200001a 33554458 (21: nrow: 116)  |
leaf: 0x200001b 33554459 (22: nrow: 116)  |
leaf: 0x200001c 33554460 (23: nrow: 116)  |
leaf: 0x200001d 33554461 (24: nrow: 116)  |(3)
leaf: 0x200001e 33554462 (25: nrow: 116)  |
leaf: 0x200001f 33554463 (26: nrow: 116)  |
leaf: 0x2000020 33554464 (27: nrow: 116)  |
leaf: 0x2000021 33554465 (28: nrow: 116)  |
leaf: 0x2000022 33554466 (29: nrow: 116)  |
leaf: 0x2000023 33554467 (30: nrow: 116)  |
leaf: 0x2000024 33554468 (31: nrow: 116)  |
leaf: 0x2000025 33554469 (32: nrow: 116)  |
leaf: 0x2000026 33554470 (33: nrow: 116)  |
:                      |
:                      |
leaf: 0x200002d 33554477 (40: nrow: 116)  |
leaf: 0x200002e 33554478 (41: nrow: 116)  |
leaf: 0x200002f 33554479 (42: nrow: 116)  (2)
leaf: 0x2000030 33554480 (43: nrow: 116)
leaf: 0x2000031 33554481 (44: nrow: 116)
leaf: 0x2000032 33554482 (45: nrow: 116)
leaf: 0x2000033 33554483 (46: nrow: 116)
leaf: 0x2000034 33554484 (47: nrow: 116)
:
:
leaf: 0x2000058 33554520 (83: nrow: 116)
leaf: 0x2000059 33554521 (84: nrow: 116)
leaf: 0x200005a 33554522 (85: nrow: 24)
↑        ↑
Leaf No.  キーの数
----- end tree dump

上記のTREEDUMPをもとに、インデックスに対するI/O = 45回を説明すると・・・

(1)ブランチ・ブロックを読み、5000件目の値である10050000が格納されている
DBAを求める

(2)5000件目の値10050000が格納されているリーフ・ブロック番号42を読む

(3)条件式が以下全て(EMPNO01 <= 10050000)なのでリーフ・ブロック番号
42 ~ -1までのブロックを読む

●検索イメージ

次回は、このテーブルを100万件まで拡張させ、リーフ分割が多発する様子を見
ていく。

海開き 茅ヶ崎にて

~インデックスに関する検証 その4~
by つけまい