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

こんにちは！データベースエンジニアとして日々、クエリの海を泳いでいる私です。

皆さんは、何か調べ物をするときに「手元のメモ帳」だけで完結したらすごく楽だと思いませんか？わざわざ遠い資料室まで走ってファイルを探しに行かなくて済むなら、仕事のスピードは何倍にもなりますよね。

実は、PostgreSQLのクエリを爆速にする「カバリングインデックス」と、その切り札である「INCLUDE句」というテクニックは、まさにこの「手元のメモ帳」を強化する魔法のようなものなんです。

今日は、初心者の方でも直感的にわかるように、データベースの裏側で何が起きているのかを紐解いていきましょう。

—

データベースでデータを探すとき、インデックスは「本の巻末にある索引」のような役割を果たします。

例えば、100万人の社員名簿から「山田太郎」さんの電話番号を探すとしましょう。索引がなければ、最初から順番に全員の名前を見ていくしかありません。これは大変ですよね。索引があれば、「山田」のページをすぐ開いて、そこに書かれた電話番号を読み取るだけで済みます。

でも、ここで一つ問題があります。もし、索引に「電話番号」が載っていなかったらどうなるでしょう？

1. 索引で「山田太郎」の場所を見つける。
2. その横に書かれた「社員番号」を頼りに、本の中のページ（ヒープと言います）までわざわざ移動する。
3. そこでようやく「電話番号」を確認する。

この「わざわざ本の中身まで見に行く」という移動プロセスが、実はデータベースにとって一番の「重労働」なんです。

ここで登場するのが「カバリングインデックス」という考え方です。

さっきの例で言えば、索引に最初から「電話番号」まで書き込んでおけばいいわけです。そうすれば、索引を見ただけで全てが完結しますよね。これをデータベースの世界では「インデックスオンリースキャン」と呼びます。

「本の中身（テーブル本体）」を見に行く必要がないので、驚くほど速くなるんです。

さて、ここからが今日の本題です。

普通、インデックスには「検索のキーになる列」を含めます。例えば「名前」で検索するなら、名前をインデックスにしますよね。でも、「名前」と「電話番号」の両方をインデックスに含めようとすると、データベース内部の仕組み上、ちょっとした制限やオーバーヘッド（余分な負荷）が発生することがあります。

そこで便利なのが `INCLUDE` 句 です。

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

この書き方、すごくないですか？
「`name` は検索の目印としてガッツリ使うけれど、`phone_number` はただ横に添えておいてくれればいいよ」という指定ができるんです。

こうすることで、以下のメリットが生まれます。

検索性能を維持できる: インデックスをコンパクトに保てるので、検索が遅くなりません。
ヒープアクセスを回避できる: 欲しいデータがインデックスの中に「おまけ」としてくっついているので、わざわざテーブルの本体（ヒープ）までデータを取りに行く必要がありません。

このテクニックは、以下のようなケースで特に輝きます。

逆に、何でもかんでも `INCLUDE` してしまうとインデックスのサイズが肥大化して、かえってメモリを圧迫してしまいます。「よく使うクエリ」を一つずつ選んで、慎重に適用していくのが、デキるエンジニアのコツですね。

—

データベースのチューニングって、難しく考えがちですが、実は「いかに無駄な移動を減らすか」という日常の整理整頓と似ています。

1. まずはインデックスで目印を付ける。
2. それでも遅いなら、INCLUDE句で「必要なメモ」を索引に書き込んでおく。

これだけで、あなたの書くSQLは一段上のスピードを手に入れるはずです。

もし今、システムが重いと感じている箇所があったら、一度そのクエリが「本当にヒープまで見に行っているのか？」を確認してみてください。`EXPLAIN` コマンドで「Index Only Scan」の文字が見えたら、それはもう勝ちですよ！

それでは、今日も快適なデータベースライフを！また次回の記事でお会いしましょう。