複合インデックスの列順序と左端プレフィックス則

複合インデックスは「連結キー1本」である

複合インデックス(マルチカラムインデックス)とは、複数の列をまとめて1つのキーにした B+Tree です。(a, b, c) という複合インデックスは、a で並べ、a が同じものは b で並べ、b も同じものは c で並べる、という 辞書順(lexicographic order) で葉を整列させます。電話帳が「姓 → 名」の順で並ぶのと同じ構造です。

ここを誤解すると設計を誤ります。(a, b, c) は「a のインデックスと b のインデックスと c のインデックスの集合」ではありません。a・b・c を連結した1本の複合キーで葉が並んだ、たった1本の木 です。葉のキー比較は常に先頭列から始まり、先頭列で差がついた時点で残りの列は比較されません。

(a, b, c) インデックスの葉の並び(辞書順)
  (1, 'x', 10)
  (1, 'x', 30)
  (1, 'y', 5)
  (2, 'a', 99)
  (2, 'a', 100)
  ...
a で大分類、a 内で b、b 内で c。a を飛ばして b だけで並ぶことは絶対にない。

左端プレフィックス則

この並びから、インデックスが使える条件が一意に決まります。それが 左端プレフィックス則(leftmost prefix rule) です。複合インデックス (a, b, c) は、先頭の列から連続した接頭辞を WHERE で指定したときにだけ、絞り込みに使えます。

要点は「先頭列から連続して固定できたぶんだけ、目的の行が葉上で連続した1区間に集まる」ことです。a を固定すれば該当行は隣り合う葉に固まり、B+Tree は範囲の先頭を1回で見つけて葉リンクを順次たどれます(この仕組みは B+Tree の内部構造 を参照)。ところが b だけを指定すると、b='y' の行は a=1 の区画にも a=2 の区画にも散らばっており、葉上で連続しません。連続しない以上、範囲スキャンの起点を1つに定められず、インデックス全体を走査するしかなくなるのです。

等値が先、範囲は後 ——「範囲列で並びが終わる」

列順を決める最重要原則が、等値述語の列を先頭側に、範囲述語の列を末尾側に置く ことです。理由は B+Tree の整列の性質にあります。

ある列に範囲条件(>、BETWEEN、LIKE 'abc%' など)が来ると、その列で複数の値にまたがります。複合キーの辞書順では、先行列が同値の範囲内でしか後続列は整列していない ため、先行列が複数値にわたった瞬間に、後続列の並びは全体としては崩れます。

-- (status, created_at) というインデックスを想定
SELECT * FROM orders
WHERE status = 'paid'              -- 等値:先頭で1値に固定
  AND created_at >= '2026-06-01';  -- 範囲:末尾で連続区間を取る

status='paid' で先頭が1値に固定されるので、その内部では created_at が昇順に連続して並びます。よって created_at の範囲は葉上の連続区間になり、範囲スキャンが綺麗に効きます。逆に列順を (created_at, status) にすると、created_at の範囲指定で先頭が複数日にまたがり、その各日の中でしか status は整列していないため、status='paid' での絞り込みはインデックスでは効かず、行ごとのフィルタに落ちます。

ソート(ORDER BY)とカバリング

複合インデックスの並びは、絞り込みだけでなく ORDER BY のソート省略 にも直結します。インデックスの列順とソート列の順・方向が一致すれば、DB は葉を順にたどるだけで整列済みの行を得られ、明示的なソート処理(Sort ノード)を消せます。

-- (user_id, created_at) のインデックスがある
SELECT * FROM posts
WHERE user_id = 42
ORDER BY created_at DESC;   -- user_id 固定 → created_at 順は葉の並びそのもの

user_id=42 で先頭が固定され、その区画内は created_at 順に並ぶので、葉を降順にたどれば ORDER BY created_at DESC を追加コストなしで満たせます。なお SELECT する列がすべてインデックスに含まれる場合は、テーブル本体を読まずインデックスだけで応答が完結する カバリングインデックス(covering index / index-only scan) になり、ランダムな本体アクセスを省けます。これらが効くかどうかは実行計画で確認します(クエリ最適化、内部のコスト見積もりは オプティマイザの内部 を参照)。

スキップスキャン ——左端プレフィックス則の例外

「先頭列が WHERE に無いと使えない」は原則ですが、例外があります。スキップスキャン(skip scan / loose index scan) です。Oracle・MySQL 8.0(InnoDB)・PostgreSQL(18 以降の B+Tree)などが実装しています。

仕組みはこうです。先頭列 a の異なる値(distinct value)が少数しかない場合、DB は「a の各値ごとに、後続列の条件で内部的に小さな範囲探索を繰り返す」ことで、先頭列が指定されていなくてもインデックスを部分的に使えます。

(status, created_at) インデックスで status を指定しないクエリ
  WHERE created_at = '2026-06-01'
スキップスキャンの内部動作(status の distinct = paid, shipped, canceled の3値なら):
  status='paid'     の中で created_at='2026-06-01' を範囲探索
  status='shipped'  の中で created_at='2026-06-01' を範囲探索
  status='canceled' の中で created_at='2026-06-01' を範囲探索
→ 3回の小さな探索の結合。フルスキャンより速いことがある。

つまり、欠けている先頭列の値を オプティマイザが内部で1つずつ補い、それぞれについて通常のレンジスキャンを走らせて結果を束ねる、というのが本質です。

列順を決める実務ルール

以上を踏まえると、複合インデックスの列順は次の優先度で決めるのが定石です。

1. 等値(=)で頻繁に絞る列を先頭へ。 左端プレフィックス則を満たし、最も多くのクエリで再利用できる。
2. その中で選択性(カーディナリティ)が高い列を優先。 1回の絞り込みで候補行を強く減らせる。
3. 範囲(>, BETWEEN, LIKE 'x%')で使う列は末尾に1つだけ。 範囲列より後ろは絞り込めないため。
4. ORDER BY / GROUP BY の列順と方向を、範囲列の後ろに合わせる。 ソート処理を省けるなら大きい。

なお JOIN のキーも本質的には等値述語なので、結合に使う列は先頭側に置くと結合アルゴリズムが有利に働きます(各方式の挙動は JOIN アルゴリズム を参照)。列順は「どのクエリを速くしたいか」から逆算するものであり、(a, b) と (b, a) は まったく別物の道具 だと理解することが、過剰なインデックス乱立を防ぐ第一歩です。