こんにちは！データベースの世界へようこそ。
普段、皆さんが何気なく使っているアプリやWebサイト。その裏側では、データベースという巨大な「図書館」が動いています。今日は、その図書館から目的の情報をいかに素早く見つけ出すか、ちょっとした「裏技」についてお話ししますね。
PostgreSQLを使っている方なら一度は耳にしたことがあるかもしれない、「カバリングインデックス（INCLUDE句）」という機能についてです。
—
本棚まで走らなくていい！「目次」を賢く使うコツ
想像してみてください。あなたは巨大な図書館で、ある本を探しているとします。
通常、目的の本を見つけるにはこんな手順を踏みますよね。
1. 図書目録（インデックス）で、本がどの棚にあるか調べる。
2. その棚までわざわざ歩いて行って（ヒープアクセス）、本を手に取る。
でも、もし図書目録の中に、「本のタイトル」だけでなく「要約」まで書いてあったらどうでしょう？
わざわざ重い腰を上げて棚まで行かなくても、目録を見ただけで「あ、この本の内容はこういうことか！」と分かってしまいますよね。これが、データベースにおける「カバリングインデックス」の考え方なんです。
—
そもそも「Index Only Scan」ってなに？
データベースの世界では、この「棚まで行く」という動作が意外とコストのかかる作業なんです。データ量が多くなればなるほど、何度も棚を行き来するのは時間がかかります。
PostgreSQLには、インデックスだけで検索を完結させる「Index Only Scan」という超高速な仕組みがあります。通常、インデックスには「検索の目印になる列」しか含まれませんが、ここに「ついでに欲しいデータ」をくっつけてしまおうというのが、今回紹介する`INCLUDE`句の役割です。
例えば、こんなケース
「ユーザーの名前（name）」で検索して、「メールアドレス（email）」を取得したいとしましょう。
SELECT email FROM users WHERE name = ‘佐藤’;
このとき、`name`だけにインデックスを貼っていると、データベースはこう考えます。
「名前は分かった！でも、メールアドレスは棚を見に行かないと分からないな……よし、棚まで行こう」
ここで、`INCLUDE`の出番です。インデックスを作る時にこう指定してあげます。
CREATE INDEX idx_users_name_email ON users (name) INCLUDE (email);
こうすると、インデックスの中に「名前」だけでなく「メールアドレス」という“メモ”が同封されます。結果として、データベースは「インデックスを見ただけで全て解決！」となり、棚まで走る必要がなくなるんです。
—
使う時のちょっとした注意点
「じゃあ、全部の列をINCLUDEに入れちゃえば最強じゃない？」と思うかもしれませんが、そこは注意が必要です。
- インデックスが太っちゃう： インデックスもデータなので、詰め込みすぎると今度はその「目録」自体が分厚くなりすぎて、読み込むのに時間がかかってしまいます。
- 更新が少し大変に： データが変わるたびに、目録の修正もしないといけません。頻繁にデータが変わる列を入れすぎると、かえって書き込み速度が落ちてしまうこともあります。
「よく使うクエリの、よく取り出す列だけ」をピンポイントで仕込む。これが、熟練のエンジニアがやっているスマートなやり方です。
—
最後に：データベースとの対話を楽しんで
データベースのチューニングは、料理の隠し味に少し似ています。
「ここで少し工夫したら、検索が速くなるかな？」と試行錯誤して、実際にクエリの実行計画を見て速度が改善したときの快感は、エンジニアならではの楽しみですよね。
もし皆さんのシステムで、「この検索、もう少し速くならないかな？」と悩んでいる場所があったら、ぜひこの`INCLUDE`というスパイスを思い出してみてください。
それでは、また次回のブログでお会いしましょう！皆さんのコードが今日も軽快に動きますように。
コメント