インデックスの仕組みを図にした。列の並び順で効くかが決まる

• インデックスが無いと先頭から全行読む
• あると途中の位置を直接特定できる
• 複合インデックスは左端から連続した組み合わせしか使えない

「サイトが遅い」の原因が、表示でもサーバーでもなく問い合わせの側にあることがある。インデックスが何をしているのかを図にした。

無いとどうなるか

MySQLの公式文書は、はっきりこう書いている。

インデックスが無いと、MySQLは最初の行から始めて、該当する行を見つけるためにテーブル全体を読み通さなければならない。テーブルが大きいほど、この代償は大きくなる。

1件を探すために、全部に目を通すことになる。行が1万件なら1万回、100万件なら100万回だ。

あるとどうなるか

同じ文書の記述はこうだ。

対象の列にインデックスがあれば、MySQLはすべてのデータを見ることなく、データファイルの途中のどの位置を探せばよいかをすばやく判断できる。これは全行を順に読むよりはるかに速い。

要点は「すべてのデータを見ることなく」にある。読む量そのものが減る。

どんなときに使われるのか

公式に列挙されている用途を整理する。

• WHERE句に合う行を素早く見つける
• 候補から行を除外する。複数の候補があるときは、もっとも行数を絞れるインデックスが選ばれる
• 結合（JOIN）で他の表から行を取る
• 指定した列のMIN / MAX を求める
• 並べ替えやグループ化。ただし使えるインデックスの左端からの場合に限る
• 必要な列がすべてインデックスに含まれていれば、インデックスだけで値を返せる

最後の点が効く場面がある。本体のデータを読まずに済むので、さらに速くなる。

左端から連続していないと使えない

ここがいちばん間違えやすい。公式の説明を引く。

複数列のインデックスがある場合、そのインデックスの左端のプレフィックスであれば、どれでも行の検索に使える。たとえば (col1, col2, col3) の3列インデックスがあれば、(col1)、(col1, col2)、(col1, col2, col3) で検索できる。

逆に言えば、col2 だけ、col3 だけでは使えない。

つまり列をどの順で並べてインデックスを作るかが、効くかどうかを決める。よく絞り込みに使う列を左に置く。

結合に使うなら型を揃える

公式には「同じ型と同じ大きさで宣言されていれば、より効率的にインデックスを使える」とある。結合するのに型が違うと、せっかくのインデックスが活きないことになる。

いつ効かないのか

万能ではない。公式はこう書いている。

インデックスは、小さなテーブルや、ほとんどの行を処理する集計系の問い合わせでは重要度が下がる。ほとんどの行にアクセスする必要がある場合、順に読むほうがインデックスを辿るより速い。

「全件を集計する」種類の処理では、むしろ順に読むほうが速い。速くする手段ではなく、絞り込む手段だと考えるほうが近い。

遅いときに見る順番

1. 何が遅いのかを測る — 表示なのか、問い合わせなのか
2. 問い合わせなら、何行触っているか見る
3. 触る行が少ないはずなのに遅いなら、インデックスを疑う
4. 条件に使っている列が、インデックスの左端から並んでいるか確かめる

推測で足すと、効かないインデックスだけが増える。測り方はサイトが遅い原因を、推測ではなく測って特定したに書いた。

まとめ

• 無いと先頭から全行読む。表が大きいほど代償が大きい
• あると途中の位置を直接特定できる
• 複合インデックスは左端から連続した組み合わせのみ有効
• 結合に使うなら、型と大きさを揃える
• 必要な列がインデックスに全部あれば、本体を読まずに返せる
• ほとんどの行を触る処理では、順に読むほうが速い

出典

• MySQL 8.4 Reference Manual「How MySQL Uses Indexes」（全表走査との比較、用途の列挙、左端プレフィックス、結合時の型、効かない場面）

図は本記事のために作成したもの。挙動はデータベース製品と版で異なるので、使っている製品の文書で確認すること。本記事は2026年10月13日時点の内容に基づく。