インデックス — 読む行を減らすための索引

What — インデックスがなぜ速いのか

インデックスの本体は B-tree（正確には B+tree）という木構造です。値を辿って目的の行に到達することで、全件を読まずに済ませます。

複合インデックスは「左から順に」しか使えない

最も実務で効くのがこの性質です。(a, b, c) という複合インデックスは、電話帳の並び順と同じです。

WHERE user_id = 1                        -- ✅ 左端のみ
WHERE user_id = 1 AND status = 'paid'    -- ✅ 左から2つ
WHERE user_id = 1 AND status = 'paid'
ORDER BY created_at DESC               -- ✅ 3つ目でソートも解決

-- ソートまでインデックスで済むと、
-- ファイルソート（メモリ/ディスク上の並べ替え）が消える

選択率（カーディナリティ）

その列が持つ値の種類の多さ。種類が多いほど絞り込みの効果が高い。性別（2種類）より、メールアドレス（全件ユニーク）のほうが効く。

カバリングインデックス

必要な列がすべてインデックスに含まれていて、テーブル本体を読まずに済む状態。非常に速い。

フルスキャン

インデックスを使わず全行を読むこと。件数が少ないテーブルなら、これが最速なこともある。

filesort

インデックスの並び順を使えず、別途ソートすること。件数が多いとディスクを使い、極端に遅くなる。

クラスタ化インデックス

主キーの順にデータ本体が並んでいる構造（InnoDB の既定）。主キー検索が最速になる一方、ランダムな主キーは挿入が遅くなる。

Why — なぜ全部の列に張ってはいけないのか

インデックスは別の表です。テーブルとは別に、値が並び替えられたデータ構造がディスクに存在します。

そのため、次のコストが発生します。

書き込みコスト。 1行 INSERT するたびに、全インデックスに新しいエントリを追加し、B-tree のバランスを保つ処理が走ります。インデックスが6本あれば、書き込みは実質7回（テーブル + 6本）。冒頭の事故はこれです。

容量。 インデックスはディスクを使います。テーブルより大きくなることも珍しくありません。

選択肢が増えることによる判断コスト。 オプティマイザはインデックスが増えるほど、どれを使うかの検討に時間をかけます。また、誤った選択をする可能性も上がります。

効かないインデックスの典型

選択率が低い列。 status が3種類、is_deleted が2種類しかない場合、WHERE is_deleted = false で絞っても90%以上の行が残ります。インデックスを辿ってから大量の行を読むより、最初から全件読んだほうが速いので、オプティマイザはインデックスを使いません。

関数を適用している列。

-- インデックスが効かない
WHERE DATE(created_at) = '2026-09-15'
WHERE LOWER(email) = 'a@example.com'

-- 効く形に書き換える
WHERE created_at >= '2026-09-15' AND created_at < '2026-09-16'
WHERE email = 'a@example.com'     -- 保存時に小文字に正規化しておく

インデックスは created_at の値で並んでいますが、DATE(created_at) の値では並んでいません。列を加工した瞬間、並び順が使えなくなります。

前方一致以外の LIKE。 LIKE 'abc%' は使えますが、LIKE '%abc' は使えません。並び順が先頭から決まる以上、末尾一致は辿れないためです。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。