データベーススペシャリスト(インデックスとアクセス手順)
今日はインデックスの話です。よくデータベースの検索スピードが遅いと
インデックスを張ればいいとかいう人がいますが・・・・。
更新系、特に基幹系のシステムでは逆効果になるケースもあったりする
ので要注意です。
1:インデックス
・B+木インデックス
バランス木なので追加、削除、更新の際にすべてのリーフページの深さ
(階層レベル)が同じになるようにメンテナンスされる。
※ルートページを除く各ページ内の利用率が50%以上になるようメンテナンス
※B木インデックスの位数がnのとき最大「2n+1」の下位ページをもつ。
6:表の結合方法
インデックスを張ればいいとかいう人がいますが・・・・。
更新系、特に基幹系のシステムでは逆効果になるケースもあったりする
ので要注意です。
1:インデックス
・B+木インデックス
バランス木なので追加、削除、更新の際にすべてのリーフページの深さ
(階層レベル)が同じになるようにメンテナンスされる。
※ルートページを除く各ページ内の利用率が50%以上になるようメンテナンス
※B木インデックスの位数がnのとき最大「2n+1」の下位ページをもつ。
ORDER BY句でもインデックス効率を低下させないようにしたのがB+木
ハッシュ関数の値からデータの位置情報を求めてそこから行識別子(ROWID)
を求める。
を求める。
衝突(コンフリクト):同じ関数値が求まってしまう。
同義語(シノニム):同じ関数値のキー値同士
格納される値の種類が少ない場合に使われる。データウェアハウスで有利。
・リンクインデックス
ポインタによって主キー⇔外部キーの参照を高速化
他のインデックスと組み合わせるとさらに高速化する。
結合キーで検索するときに高速化するインデックス
・その他のインデックス
n-gramインデックス:全文検索用
四分木インデックス:地図などの空間情報検用
UB木インデックス : B木の改良版検索効率を向上させているよう
2:インデックスの効果と弊害
アクセスデータ絞り込みによるI/O回数とCPU時間の削減
キー値順[昇順、降順]の行データ取得によるソート処理削除
*キー値の種類が多いほどキー値の重複が少なくなりインデックスによる
絞込み率もよくなるため検索効率がよくなる。
大量データのランダムアクセスによるI/Oの増加
データ更新時のインデックスメンテナンスによるオーバーヘッド増大
複数(n)行検索時の参照データページ数を削減する効果がある。
I/O削減:ヒット行数/ページ内平均行数
※ヒット行数≧表格納データページ数=インデックスは使わないほうがいい。
※絞込率が10~15%以下ならインデックスは使わないほうがいい。
4:検索条件と複数列インデックスのサーチ範囲
インデックスのキーが複数の列から構成されるインデックス
※「=」条件の場合はインデックスを用いて行を絞り込める。
5:アクセス手順
・表のアクセス方法
インデックスを用いないアクセス=表スキャン
インデックスを利用したアクセス=インデックススキャン
インデックスだけを参照するアクセス=キースキャン
・複数インデックスを利用するアクセス(ANDの場合)
複合表に対してインデックスを利用するのが効果的
・複数インデックスを利用するアクセス(ORの場合)
両方の条件についてインデックスが利用出来る方がいい。
AND→共通部分、OR→集合和
・複数のビットマップインデックスを利用する
結果の行の集合を表すビットマップを求めることができる。
5:アクセス手順
・表のアクセス方法
インデックスを用いないアクセス=表スキャン
インデックスを利用したアクセス=インデックススキャン
インデックスだけを参照するアクセス=キースキャン
・複数インデックスを利用するアクセス(ANDの場合)
複合表に対してインデックスを利用するのが効果的
・複数インデックスを利用するアクセス(ORの場合)
両方の条件についてインデックスが利用出来る方がいい。
AND→共通部分、OR→集合和
・複数のビットマップインデックスを利用する
結果の行の集合を表すビットマップを求めることができる。
AND→ビット席、OR→ビット和
・ビットマップインデックスとB+インデックスを利用するアクセス
ビットマップ→ROWIDに変換
ROWID→ビットマップに変換
・ビットマップインデックスとB+インデックスを利用するアクセス
ビットマップ→ROWIDに変換
ROWID→ビットマップに変換
6:表の結合方法
・入れ子ループ結合(Nested-LoopJoin)
結合する各表の検索を入れ子にする。m行の表とn行の表で
処理すると「m×n」の負荷となる。=左外結合と右外結合を表現可能
・併合結合(MergeJoin)
作業表を作成してそれらの作業表を結合キーでソートして突き合わせ
ソート行数が多いと負荷が大きくなってしまう。
=完全外結合にも対応
・ハッシュ結合(HashJoin)
ハッシュ表を作成してインデックスの代わりにハッシングを行って結合
ハッシュ表のためのメモリ容量が必要
= 結合条件が「=」の等結合の場合のみ使用可能
この部分は多分、SQLよりかなり重要、データベースの根幹がどう動いているかに
関わってくるところ。B+木インデックスとかはRDBの根本の理論なので、それを
押さえておかないときちんとしたパフォーマンスを出せないです。
後はメモリと外部記憶の書出のところかな、この辺がデータベースの性能のキモ
ですな。
◆メモ
http://eetimes.jp/content/3857
http://ja.wikipedia.org/wiki/%E7%B4%A2%E5%BC%95_%28%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%29
http://msdn.microsoft.com/ja-jp/library/ms191195.aspx
http://homepage3.nifty.com/suetsuguf/en02.pdf
http://www.oracle.com/technology/global/jp/pub/jp/db_magazine/mongai/chapter3_1.html
http://www.geocities.jp/a1770053/jyoho/mca_db/chapter5.htm
結合する各表の検索を入れ子にする。m行の表とn行の表で
処理すると「m×n」の負荷となる。=左外結合と右外結合を表現可能
・併合結合(MergeJoin)
作業表を作成してそれらの作業表を結合キーでソートして突き合わせ
ソート行数が多いと負荷が大きくなってしまう。
=完全外結合にも対応
・ハッシュ結合(HashJoin)
ハッシュ表を作成してインデックスの代わりにハッシングを行って結合
ハッシュ表のためのメモリ容量が必要
= 結合条件が「=」の等結合の場合のみ使用可能
この部分は多分、SQLよりかなり重要、データベースの根幹がどう動いているかに
関わってくるところ。B+木インデックスとかはRDBの根本の理論なので、それを
押さえておかないときちんとしたパフォーマンスを出せないです。
後はメモリと外部記憶の書出のところかな、この辺がデータベースの性能のキモ
ですな。
◆メモ
http://eetimes.jp/content/3857
http://ja.wikipedia.org/wiki/%E7%B4%A2%E5%BC%95_%28%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%29
http://msdn.microsoft.com/ja-jp/library/ms191195.aspx
http://homepage3.nifty.com/suetsuguf/en02.pdf
http://www.oracle.com/technology/global/jp/pub/jp/db_magazine/mongai/chapter3_1.html
http://www.geocities.jp/a1770053/jyoho/mca_db/chapter5.htm
コメント