インデックス（なぜ速くなるか）

なぜ速くなる？ 全表スキャンとの対比

WHERE email = 'a@example.com' という検索を考えます。インデックスが無ければ、DB は先頭行から1行ずつ「これか？違う」を繰り返します。これが全表スキャン（フルスキャン）。100万行あれば最悪100万回の照合です。

一方インデックスがあると、ソート済みの索引をたどって目的の行の在りかだけを取り出し、本体へ直行します。比較回数は「全部」から「木の深さ（数回〜十数回）」へ激減します。

中身は B-tree（バランス木）

多くの DB の既定インデックスは B-tree（厳密には B+tree） という木構造です。ポイントは2つ。

• 常にソート済み：キーが順番に並んでいる。だから「= の一致」だけでなく、>・<・BETWEEN のような範囲検索や ORDER BY にも効きます。
• 木の高さが低く保たれる（バランス）：データが増えても木は浅いまま自動調整され、どの行を探してもほぼ一定の少ない手数でたどり着けます。これが O(log N) の正体です。

-- email に B-tree インデックスを作成
CREATE INDEX idx_users_email ON users (email);

-- 等価検索も…
SELECT * FROM users WHERE email = 'a@example.com';
-- 範囲検索も索引が効く（ソート済みだから）
SELECT * FROM users WHERE created_at >= '2026-01-01';

トレードオフ ── タダではない

インデックスは「読み取りを速くする代わりに、別のコストを払う」取引です。

複合インデックスと「列の順序」

複数の列をまとめた 複合インデックス（マルチカラムインデックス） では、列を並べる順序が決定的に効きます。電話帳が「姓 → 名」の順に並んでいるのと同じで、前方の列から順に使えるという性質（左端プレフィックスの原則）があります。

-- (last_name, first_name) の順で作成
CREATE INDEX idx_name ON users (last_name, first_name);

電話帳で「名（太郎）」だけを手がかりに探すと結局めくる羽目になるのと同じ理屈です。よく単独で絞り込む列を先頭に置くのがコツです。

インデックスが「効かない」よくあるケース

索引を貼ったのに使われない、という落とし穴は典型パターンが決まっています。

-- ✕ 列を加工 → 多くの DB で索引が効かない
SELECT * FROM users WHERE LOWER(email) = 'a@example.com';
SELECT * FROM orders WHERE YEAR(created_at) = 2026;

-- ○ 列はそのまま、右辺側を調整する
SELECT * FROM orders
WHERE created_at >= '2026-01-01' AND created_at < '2027-01-01';

そのほか効きにくくなる代表例：

• 前方一致でない LIKE：LIKE 'abc%'（前方一致）は B-tree が効きますが、LIKE '%abc' のように先頭にワイルドカードが来ると、並び順を手がかりにできず効きません。
• ヒット率が高すぎる条件：前述のとおり、ほぼ全行が当てはまるなら全表スキャンが選ばれます。
• データ量が小さい：数十行のテーブルは、索引を経由するより全部読んだ方が速く、そもそも使われないことがあります。

まとめ

• インデックス＝本の索引。全表スキャン O(N) を、索引経由の O(log N) に変えて検索を速くする。
• 実体はソート済みの B-tree。だから等価検索だけでなく範囲検索・並べ替えにも効く。
• ただし読みは速く・書きは遅く・容量は増えるトレードオフ。使う列に絞って貼る。
• 複合インデックスは列順が命。加工した列・先頭ワイルドカード LIKE では効かない。EXPLAIN で確認する。

絞り込みの速さは JOIN や トランザクション と並んで DB 性能の土台です。索引が前提とする整列の感覚は 正規化 を学ぶとさらに腑に落ちます。