【入門編】カバリングインデックス (INCLUDE句) – PostgreSQL

こんにちは！データベースエンジニアの技術ブログへようこそ。

今日は、PostgreSQLのちょっとした「裏技」……といっても、知っていると劇的にパフォーマンスが変わる「カバリングインデックス（INCLUDE句）」についてお話しします。

「インデックス」という言葉を聞くと、なんとなく「本の後ろにある索引」をイメージしますよね。実はデータベースの世界でも考え方は全く同じなんです。でも、たまに「せっかく索引を見たのに、結局本文まで確認しに行かなきゃいけない」という、ちょっともどかしい状況が発生することがあるんです。

今日は、そんな「二度手間」を解消する魔法のテクニックを一緒に紐解いていきましょう！

—

想像してみてください。あなたは巨大な図書館で、ある特定の著者の「名前」と「電話番号」が書かれた名簿を探しているとします。

通常のインデックス（索引）は、「名前」順に並んでいます。

あなたは「あ」さんの電話番号が知りたい。索引を見て「10ページだ！」と分かりましたよね。でも、電話番号までは索引に載っていないので、わざわざ10ページ目まで歩いていって、名簿を確認しなければなりません。

これがデータベースの世界でいう「インデックスは使ったけど、結局データ本体（テーブル）を見に行かなきゃいけない」という状態です。これ、データ量が増えると結構なタイムロスになるんです。

ここで、「もし索引の中に、最初から電話番号も一緒に書いてあったらどうなる？」と考えてみてください。

「あ」さんの行に、「10ページ目、電話番号：090-xxxx-xxxx」と書いてあれば、もう10ページ目まで歩く必要なんてありませんよね！索引だけを見て、目的の情報をすべてゲットできる。

これがPostgreSQLの「INCLUDE句」がやっていることです。

例えば、「ユーザーテーブル」から「名前」で検索して「電話番号」を取得したい場合、こんなふうにインデックスを作ります。

CREATE INDEX idx_user_name_phone
ON users (name)
INCLUDE (phone_number);

こうすると、`name`は検索のための「キー」として使われ、`phone_number`は「付録」としてインデックスの中にひっそりと格納されます。

—

このテクニック、一見すると「全部インデックスに入れちゃえば最強じゃん！」と思うかもしれません。でも、ちょっと待ってくださいね。

メリット： 「インデックスのみスキャン（Index Only Scan）」という最高に速い読み取りができるようになります。特に、特定の列だけを頻繁に取得するような「読み取り専用」に近い処理では、爆速になります。
注意点： インデックスの中にデータを持つので、当然その分だけサイズが大きくなります。また、データが書き換わるたびにインデックスも更新しなければならないので、頻繁に更新（UPDATE）が走る列には向きません。

「読み取りが多くて、たまにしか更新されないデータ」に対して使うのが、この魔法を一番うまく使いこなすコツです。

いかがでしたか？「カバリングインデックス」なんて難しい名前ですが、要は「必要な情報をひとまとめにして、無駄な移動を減らす」という、すごく人間味のある工夫なんです。

データベースも、私たち人間と同じで「いかに無駄を省いて効率よく動くか」を常に考えてあげると、ものすごくいいパフォーマンスで応えてくれます。

まずは、皆さんが普段触っているテーブルで、「いつもセットで検索している列」がないか探してみてください。もしあれば、この`INCLUDE`を試す絶好のチャンスです！

また次回の記事でお会いしましょう！もし「もっとこういったケースはどうなの？」という疑問があれば、ぜひコメントで教えてくださいね。一緒に深掘りしていきましょう！