チューニング

インデックス入門 — 仕組みと基本

インデックスの正体と B-Tree の仕組み、フルスキャンとの違い。最初の一歩。

インデックスとは

インデックスは、テーブルの特定の列に対して作る「検索用の索引」です。本の巻末にある索引と同じ発想で、「この値を持つ行がテーブルのどの位置にあるか」をあらかじめソート済みの構造で保持しておきます。

実体は独立したデータ構造（多くは B+Tree）で、テーブルとは別にディスクに保存されます。CREATE INDEX で作成し、クエリ実行時にはオプティマイザが自動で「インデックスを使うか / フルスキャンするか」を判断します。開発者がヒントを書かなくても、適切なインデックスがあれば勝手に使われるのが基本です。

代表的な種類:

B-Tree インデックス: 等値・範囲検索・ソートに強い汎用型。デフォルト
ユニークインデックス: 値の重複を禁止する制約を兼ねる（主キーは自動的にこれ）
部分インデックス / 式インデックス: 特定条件の行だけ、または関数の結果に対して貼る
ハッシュ・GIN・GiST など: 全文検索や範囲型など用途特化のインデックス

sql

-- 基本的なインデックス作成
CREATE INDEX idx_users_email ON users (email);

-- ユニーク制約兼インデックス
CREATE UNIQUE INDEX idx_users_email_u ON users (email);

-- 部分インデックス (PostgreSQL)
CREATE INDEX idx_orders_active ON orders (created_at)
  WHERE status = 'active';

なぜインデックスで速くなるのか

インデックスがない検索はテーブル全体を 1 行ずつ走査（フルスキャン）します。1,000 万行あれば 1,000 万回の比較。インデックスはこれを探索木のたどり直しに置き換え、数十回の比較で目的行に到達できるようにします。

RDBMS のデフォルトインデックスはほぼすべて B-Tree（厳密には B+Tree）。木の段数は概ね log(行数) で増えるため、行数が増えても検索コストはほとんど増えません。1,000 万行でも木の深さは 4〜5 段程度。

ただしインデックスにもコストがあります: 書き込みのたびに木を更新する必要があり、ディスク容量も消費します。次ページ以降で、複合インデックスやカバリング、インデックスの設計指針を段階的に学んでいきましょう。

次のステップ

インデックスの基本を押さえたら、次は複合インデックス（複数列をまとめて貼る）とカバリングインデックス（テーブル本体を読まずに完結させる）を学びましょう。単一列のインデックスだけでは太刀打ちできない現実のクエリ最適化で必須のテクニックです。