前回、TREEDUMPを基に、インデックスに対してどのようにアクセスしていくかという様子を見てきた。今回は、この1万件のテーブルを100万件まで拡張させ、リーフ分割が多発する様子を見ていく。テーブルTEST01(1万件)に対して、リーフ分割を多発させながら100万件まで拡張させた結果(イメージ)を示す。●100万件まで拡張した過程の説明1.現行の10000010~10100000までの1万件に、さらに10100010~11000000までの9万件(増分10)を挿入し、合計10万件のテーブルに拡張(末尾がすべて0)2.10000001~10999991までの10万件(増分10)を挿入し、合計20万件のテーブルに拡張(末尾がすべて1)3.以後、末尾が2~9までの各10万件(増分10)を順にそれぞれ挿入し、10000001~11000000までの合計100万件のテーブルに拡張なんだかややこしい説明になってしまったが、つまりはリーフ分割を多発させたいがために、このような既存のキーとキーとの間に新しいキーの挿入を繰り返しただけのことなので、拡張の過程についてはあまり深い意味はない。昇順で100万件のテーブルを作成したよりは、リーフ分割を頻発させている分だけ、リーフ・ブロックの数が多いことだけを認識していただければよい。この100万件に拡張したテーブルTEST01に対して、1万件の時と同様の検索を行った結果を示す。検索結果を簡単に説明すると、<検索1>と<検索2>はともに100万件の真中である50万件目の値10500000をイコール検索したものである。数が2から3に増えていることだ。HEIGHTを参照)、1万件中の5000件目を検索するのと、100万件中の50万件目を検索するのとでは、アクセスするブロックが1つ増えるだけで、パフォーマンスに影響を及ぼすものではない。<検索3>のインデックスに対するI/O回数が、1万件の時と同様1~5000件目までのレンジ検索なのに、45から72に増えているのは、下記のTREEDUMPをご覧になっていただければお分かりの通り、リーフ分割を繰り返した結果1リーフ・ブロック当たりのROWIDの密度が低くなったからである。その他の値については、1万件から100万件にデータが増えたわけであるから、それに伴ってI/O回数が増えるのは当然の結果である。;索引が分析されました。dump拡張前と拡張後を比較していただければお分かりの通り、1リーフ・ブロック当たりに格納されているインデックス・キーの数が少なくなっている。順)に挿入が行われたため、リーフ分割が多発し、その結果1リーフ・ブロック中に格納されるインデックス・キーの数が62~81と少なくなってしまったのである。次回は、この100万件のテーブルに対して大量の削除を行った結果、インデックス検索が全件検索よりも遅くなるという不可解な動きについての検証を行う。reserved.トップページ企業概要プライバシーポリシ。