🐔

DBのIndex(IPAのDBスペシャリスト対策)

2025/10/04に公開

1.クラスタ化インデックスと非クラスタ化インデックス

テーブルの実データそのものをインデックス順に並べ替える仕組み。当然、１つのテーブルに１つしか設定できない。

実データとは別に「検索用の辞書（索引）」を作成する仕組み。
テーブル本体の並び順はバラバラだが、インデックスには順序が与えられている。

例えば、「学科コード、学籍番号(主キー)、数学のテストの点数」の３列からなるテーブルを考える。

CREATE TABLE student_score (
  dept_code   CHAR(2),
  student_id  INT PRIMARY KEY,   -- クラスタ化インデックスになる（多くのDBで）
  math_score  INT
);

このとき、多くのRDBMSでは PRIMARY KEY にクラスタ化インデックスが張られ、
テーブル本体は student_id 順に物理的に並んでいる。

CREATE INDEX idx_math_score ON student_score(math_score);

このとき、DB内部には「別のB+木」ができて、キーは math_score で昇順に管理される。
各キーの葉ノードには「対応する行のポインタ（RowID または PK）」が格納される。

例（概念イメージ）：

インデックス: math_score
  40 → student_id = 1023
  55 → student_id = 1005
  70 → student_id = 1002
  70 → student_id = 1008
  90 → student_id = 1011

SELECT * FROM student_score WHERE math_score = 70;

SELECT * FROM student_score ORDER BY student_id;

SELECT * FROM student_score ORDER BY math_score;

非クラスタ化インデックスがすでに点数順で並んでいるので、これをなぞれば良い。
ただし、実データを取りに行くのにページへのランダムI/Oが発生する。
→ 大量件数だとコストが高い。
「SELECT math_score FROM ...」のようにインデックス列だけを参照する場合、テーブル本体を参照せずインデックスだけで完結する。一方「SELECT *」の場合は必ずランダムI/Oが発生する。

検索機能自体は同じ
実データを取りに行くときに、クラスタ化インデックスの場合は特定のページに固まっているが、非クラスタ化インデックスの場合は散らばっているのでページへのランダムI/Oが発生する。

※では巨大なページを作ればいいかというと、ページロックの場合の粒度や、キャッシュ効率の悪化などの問題が発生するので、そういうわけにもいかない。

主索引とは、「主となる索引」というような曖昧なものではなく、「主キーに付与する索引」という意味であり、副次索引とは主キー以外の項目に対して付与する索引である。主キーが複数の列からなる場合、その一部の列に対して付与する索引も副次索引となる。