インデックス

この講座のチャプター1で「データベースは100万件から狙った1件を一瞬で取り出せる」と言いました。この章では、その速さの正体を明かします。そして、速さは自動ではありません。どの検索を速くするかは、あなたが設計します。その道具がインデックスです。

全件確認

まず、インデックスがないときデータベースが何をしているかから確認します。

SELECT * FROM users WHERE name = '佐藤';

このとき、データベースは先頭の行から順に、全行のnameを確認します。この動きをフルスキャン、正確にはシーケンシャルスキャンと呼びます。6人のusersなら一瞬です。しかし100万人なら100万回の確認が必要です。「配列は探すのが遅い」のと同じ理屈で、データ量に比例して遅くなるO(n)の検索です。

ここで思い出してほしいのは、主キーでの検索は最初から速いということです。WHERE id = 4 は100万件でも一瞬です。なぜなら、主キーには自動でインデックスが作られているからです。つまりあなたは、速い検索をすでに使っていたのです。この章でやるのは、その速さをid以外の列にも足すことです。

インデックスの正体

インデックス(index)は、直訳すると「索引」です。分厚い技術書で「JOIN」の説明を探すとき、1ページ目から順にめくる人はいません。巻末の索引を開き、五十音順に並んだ見出しから「JOIN …… 142ページ」を見つけて、直接142ページに飛びます。

データベースのインデックスも、まったく同じ仕組みです。ある列にインデックスを作ると、データベースはその列の値を並べ替えた索引データを、テーブルとは別に作って持ちます。

以下はusersのname列にインデックスを作った場合のイメージです。

WHERE name = '佐藤' が来たら、テーブル本体ではなく、まずこの索引を引く。並んでいるので、頭から全部見る必要がなく、辞書を引く要領で一気に狙いの場所へ飛べます(「並んでいると、なぜ一気に飛べるのか」の正確な仕組みは、探索アルゴリズムの話になります。このコースでは「五十音順の辞書は、頭から読まなくても引ける」という実感で十分です)。100万件でも、確認は数十回で済みます。これが「一瞬で取り出せる」の正体です。

CREATE INDEX

CREATE INDEX idx_users_name ON users (name);