やあ！今日もデータベースと格闘しているかな？
PostgreSQLを触っていると、一度は「検索を速くしたい！」という壁にぶつかるはずだよね。そんな時、みんな最初に考えるのが「インデックス（索引）」だと思う。
今日は、そのインデックスをさらに一歩進化させて、パフォーマンスを劇的に向上させる「カバリングインデックス（INCLUDE句）」について、ちょっと面白い例え話で解説してみるよ。
—
インデックスは「辞書の索引」と同じ
まず、インデックスの基本からおさらいしよう。
例えば、分厚い辞書で「りんご」という単語を調べたいとき、どうする？ ページを最初から1枚ずつめくらないよね。巻末の索引（インデックス）を使って、「りんごは120ページにあるな」と調べてから、120ページに飛ぶはず。
データベースのインデックスもこれと全く同じ仕組みなんだ。
「索引」だけで答えが出せたら、もっと速くない？
さて、ここからが本題。
もし辞書の索引に、「120ページ」という場所だけでなく、「意味：赤い果物」まで小さく書いてあったらどうだろう？
わざわざ120ページを開かなくても、索引を見ただけで「ああ、りんごは赤い果物なんだな」と答えが分かっちゃうよね。本をめくる手間（＝ディスクへのアクセス）が省ける分、めちゃくちゃ速くなると思わない？
これが、PostgreSQLの「カバリングインデックス」の考え方なんだ。
INCLUDE句で「おまけ情報」を忍ばせる
PostgreSQLでは、`CREATE INDEX`をするときに、`INCLUDE`という魔法の言葉が使える。
普通、インデックスを作る時は「検索の条件に使う列」を指定するよね。でも、`INCLUDE`を使うと、「検索条件には使わないけど、結果として表示したい列」をインデックスの中にこっそり含めておくことができるんだ。
例えば、ユーザー名で検索して、その人のメールアドレスも知りたいという場合なら、こんな感じで書くよ。
CREATE INDEX idx_users_name_email
ON users (name)
INCLUDE (email);
こうすると、データベースは「名前」で検索するだけでなく、インデックスの中に「メールアドレス」という答えも一緒に持っておいてくれる。結果、本来のテーブルデータを見に行く必要がなくなって、Index-Only Scan（インデックスだけで検索が完了する状態）という、めちゃくちゃ効率的な動きをしてくれるようになるんだ！
なぜこれが「神テクニック」なのか？
この方法には、初心者の方でもぜひ覚えておいてほしいメリットが2つあるよ。
1. ディスクへの往復が減る（＝爆速になる）
テーブル本体を読みに行くのは、実はデータベースにとってかなり重い仕事なんだ。インデックスだけで答えが出せれば、その重い仕事をしなくて済む。これが一番のメリットだね。
2. 「検索用インデックス」と「表示用インデックス」を分ける必要がない
「検索は速いけど、詳細を表示する時には結局テーブルを見に行かなきゃいけない」といったジレンマを、一つのインデックスで解決できるのがスマートだよね。
注意点：何でもかんでも入れればいいわけじゃない
ただし、一つだけ気をつけてほしいことがあるんだ。
インデックスに列を詰め込みすぎると、今度は「インデックス自体が巨大化」してしまう。辞書の索引が分厚くなりすぎて、もはや本と同じくらいの重さになってしまったら本末転倒だよね。
- よく検索される列は「キー（カッコの中）」に。
- 結果として表示したいだけの列は「INCLUDE」に。
この使い分けを意識するだけで、君の書くSQLは一段上のレベルに到達するはずだよ！
—
データベースの設計は、まるで整理整頓と同じ。どこに何を置いておけば一番効率よく作業できるか、そんな「気遣い」がパフォーマンスに直結するんだ。
ぜひ、今度インデックスを貼る機会があったら、この`INCLUDE`のことを思い出してみてね。きっと、君のアプリケーションも軽やかに動いてくれるはずだよ。
それじゃあ、また次回の記事で会おう！Happy Hacking!
コメント