【入門編】複合インデックスの設計 – PostgreSQL

こんにちは！データベースの世界へようこそ。
普段、何気なく使っているアプリやWebサイトの裏側で、PostgreSQLという「データの守護神」がどう働いているか、考えたことはありますか？

今日は、データベースのパフォーマンスを左右する「インデックス（索引）」、その中でも少し奥が深い「複合インデックス」について、皆さんと一緒に紐解いていきたいと思います。

専門用語を並べ立てるのは、一旦お休みしましょう。まずは、日常の風景からイメージしてみてください。

—

想像してみてください。あなたは巨大な図書館の司書さんです。膨大な本の中から、特定の1冊を探し出す必要があります。

もし、本がバラバラに置かれていたら、すべての棚を一つずつ見ていくことになりますよね。これはデータベースでいう「フルスキャン」という状態で、めちゃくちゃ時間がかかります。

そこで「インデックス」の登場です。本のタイトル順、あるいは著者名順に並べた「索引カード」を作っておけば、目的の本にすぐ辿り着けますよね。これがインデックスの正体です。

さて、ここからが本題です。もしあなたが「著者名」と「出版年」の両方を組み合わせて探したいとき、どうしますか？

ここで「複合インデックス」が登場します。例えば、索引カードを「著者名」→「出版年」の順番で並べたとしましょう。

でも、ここで注意が必要なんです。「出版年」だけで探そうとすると、急に効率が落ちてしまうんですよ。

これがデータベース界で有名な「左端一致の原則」です。
カードを「著者名→出版年」の順で束ねている以上、最初の一歩である「著者名」がわからないと、どこから探し始めればいいのか見当がつかないんですよね。

例えるなら、「名前も知らないのに、出版年だけで本を探せと言われても、図書館中の本をめくるしかない」のと同じ状態です。

複合インデックスを作るときは、「一番よく検索条件に使われる項目」を左側に置く。これが鉄則中の鉄則なんです。

初心者の方からよく「インデックスは全部に作ればいいの？」と聞かれますが、実はそれも考えものなんです。

複合インデックス： 複数の条件をセットでよく使うなら最強。でも、組み合わせの数だけ作ると、データの追加や更新が重くなってしまう（本を買うたびに、何種類ものリストを書き直さないといけないからですね）。
単一インデックス： シンプルで扱いやすい。でも、複数の条件を組み合わせた検索にはあまり強くない。

僕の経験上、まずは「アプリの画面で、ユーザーがどんな条件で絞り込みをしているか」を観察することをおすすめします。

「必ず著者名で検索してから、出版年で絞るよね」という流れがあるなら、迷わず「著者名＋出版年」の複合インデックスを作りましょう。逆に、それぞれ単独で検索される頻度が高いなら、単一インデックスを検討する余地があります。

データベースの設計に「唯一の正解」はありません。サービスの成長に合わせて、検索の使われ方も変わっていくからです。

まずは、「このカラムは検索の左側にくるかな？」と意識するだけで、あなたの設計スキルはグッと上がります。もし遅いと感じたら、その時こそがインデックスを見直す「改善のチャンス」だと思って、楽しんで取り組んでみてくださいね。

また次回の記事で、より深いテクニックについてお話ししましょう！
皆さんのデータベースライフが、少しでも軽やかになりますように。