【テクニカル・上級編】カバリングインデックス (INCLUDE句) – PostgreSQL

インデックスの「その先」へ：PostgreSQLのINCLUDE句がもたらす静かな革命

データベースのチューニングに明け暮れる日々の中で、ふと気づくことがある。どんなに複雑なクエリも、結局のところ「いかに不要なI/Oを削ぎ落とすか」という一点に集約されるということだ。

PostgreSQLのインデックス設計において、多くのエンジニアが「インデックスのみスキャン（Index Only Scan）」の恩恵に預かっているはずだ。しかし、条件句（WHERE）には含まれないけれど、SELECT句でどうしても取得したい列があるとき、私たちは長らくジレンマを抱えてきた。複合インデックスのキーを増やすべきか、それともテーブルのヒープ読み取りを甘受すべきか。

PostgreSQL 11で導入された `INCLUDE` 句は、そのジレンマに対する、控えめだが非常に強力な回答だ。今回は、この機能が内部アーキテクチャにどう影響し、どのような場面で真価を発揮するのかを深掘りしてみよう。

なぜ「INCLUDE」が必要なのか？

通常のB-treeインデックスにおいて、インデックスキーに追加された列は、そのインデックスの「順序付け」や「重複排除」の対象となる。つまり、キー列を増やすほどインデックスの肥大化を招き、木構造の深さが増し、挿入や更新のオーバーヘッドが雪だるま式に増えていく。

一方、`INCLUDE` 句で指定された列は、インデックスの「リーフページ」にのみ格納される。ここがポイントだ。

ソートには関与しない：インデックスの構造そのものには影響を与えない。
ヒープ参照を回避できる：データページ（ヒープ）にアクセスせずとも、インデックス内の値だけでSELECT結果を完結させることができる。

「検索には使わないが、結果セットには必要」というニッチな需要に対して、これ以上ないエレガントな解決策だと言える。

内部アーキテクチャからの視点：可視性マップ（Visibility Map）の重要性

ここで一つ、実務的な注意点を共有しておきたい。`INCLUDE` を使ったからといって、魔法のように常に「Index Only Scan」になるわけではない。PostgreSQLのアーキテクチャ上、インデックスのみスキャンを完結させるには、対象の行が「どのトランザクションからも可視である（最新である）」ことを確認する必要がある。

具体的には、可視性マップ（Visibility Map）が鍵を握る。インデックス内のデータがどれだけ最新であっても、PostgreSQLはヒープ上の行の状態（MVCC）を確認しなければならない。もし、テーブルが頻繁に更新されているなら、可視性マップが更新されず、結局ヒープへのI/Oが発生してしまう。

だからこそ、`INCLUDE` を駆使する際は、以下の最適化を忘れてはならない。

自動バキューム（autovacuum）のチューニング：可視性マップを効率的に更新させるため、負荷のかかるテーブルではバキュームの頻度を高める。
データの更新頻度を見極める：頻繁にUPDATEされる列を `INCLUDE` に含めるのは、インデックスメンテナンスのコストを増大させるだけになる可能性がある。

パフォーマンストラブルシューティング：いつ「やめるべき」か

現場でよくある失敗談の一つに、「とりあえず何でも `INCLUDE` すれば速くなるだろう」という考えがある。これは危険だ。

インデックスの肥大化は、メモリ（`shared_buffers`）の有効活用を阻害する。インデックスのサイズが大きくなれば、当然ながらメモリ上に載りきらなくなり、ディスクI/Oが発生する。

トラブルシューティングの際には、以下のコマンドで常にコストを確認してほしい。

EXPLAIN (ANALYZE, BUFFERS) SELECT …

`Buffers: shared hit=…` の数字に注目してほしい。もし `read=…` が頻発しているなら、そのインデックスは既に重荷になっている。`INCLUDE` を多用しすぎてインデックスのページ密度が低下し、キャッシュ効率が悪化していないか？常に自問自答する必要がある。

最後に：トレードオフを愛すること

`INCLUDE` 句は、万能薬ではない。それは「読み取りのための最適化」と「書き込みのためのコスト」という、データベースにおける永遠のトレードオフを、より精密にコントロールするための外科手術のようなものだ。

完璧なインデックスなんて存在しない。あるのは「今のワークロードに最適化された状態」だけだ。システムの成長に合わせて、一度設計したインデックスも疑ってみる。その姿勢こそが、最高峰のパフォーマンスを引き出す唯一の近道だと僕は信じている。

あなたのデータベースが、今日も静かに、そして軽快に動くことを願っている。