インデックス種別 | DB試験対策

インデックスの種類一覧

インデックスは「構造」と「用途」によって複数の種類がある。試験ではそれぞれの構造・適した用途・弱点を比較する問題が出る。

種類	構造	適した検索	弱点
B木（B-Tree）	平衡木	等値・範囲・ソート	低カーディナリティ列は非効率
ビットマップ	ビット列	低カーディナリティ列（性別など）	更新のロック競合が多い
ハッシュ	ハッシュテーブル	等値検索のみ	範囲検索・ソート不可
全文検索	転置インデックス	テキスト中のキーワード検索	構築コストが高い
空間（GiST/R木）	空間分割木	地理座標・矩形検索	汎用DBでは別途拡張が必要
クラスタ化インデックス	データ行が物理的にソート順	範囲検索・ソート	テーブルに1つしか持てない

B木インデックスの詳細

DBMSで最も広く使われる汎用インデックス。ルートノード→ブランチノード→リーフノードの階層構造。

リーフノードに（キー値、行ポインタ）のペアが格納される
O(log N) でキーを特定できる
範囲検索はリーフノードの連結リストを辿る（効率的）
複合インデックスは左端列から順に使われる（左端ルール）

B木 vs B+木：B+木はデータポインタがリーフにのみ存在し、リーフ同士が連結リストで繋がる。PostgreSQLやInnoDBのデフォルトはB+木。

ビットマップインデックス

各値について「その行がその値か否か」を 0/1 ビット列で管理する。

-- 性別列（M/F）のビットマップインデックス
-- M: 1 0 1 0 1  （1行目,3行目,5行目がM）
-- F: 0 1 0 1 0  （2行目,4行目がF）

-- AND/OR 演算でビット演算により複数条件を高速に処理
SELECT * FROM 社員
WHERE 性別 = 'M' AND 部署 = '営業';  -- 各ビットマップをAND

ビットマップインデックスは更新時に広範囲のビット列をロックするため、OLTP（更新頻度が高い）環境には不向き。DWH・分析系向き。

複合インデックスの設計指針

指針	内容
等値条件の列を先頭に	= 条件の列 → 範囲条件の列の順で配置
高カーディナリティ列を前に	一意性が高い列を先頭に置くと絞り込みが早い
ORDER BY との一致	ソートクエリと列順を合わせると追加ソート不要
カバリングインデックス	SELECT列もインデックスに含めると本体テーブルアクセス不要

-- カバリングインデックス例
CREATE INDEX idx_cover ON 受注 (顧客ID, 受注日) INCLUDE (金額);
-- 顧客IDでWHERE、受注日でORDER BY、金額をSELECT → テーブル本体不要

試験頻出ポイント

B木：等値・範囲・ソート全て対応。最も汎用的
ビットマップ：低カーディナリティ・DWH向き・OLTP不向き
ハッシュ：等値検索のみ（範囲・ソート不可）
クラスタ化インデックス：テーブルに1つだけ。物理的にデータをソートする
複合インデックスの左端ルール：先頭列をスキップするとインデックス不使用

📝 理解度チェック

ハッシュインデックスが苦手とする操作はどれか？

ビットマップインデックスがOLTP環境に不向きな理由はどれか？

クラスタ化インデックスの特徴として正しいのはどれか？

読了ボタンを누すとトップページの進捉に反柼されます

← インデックス基礎実行計画 →