データベースという底なし沼に足を踏み入れている皆さん、こんにちは。
今日も今日とて、`EXPLAIN ANALYZE`の出力結果と格闘していることでしょう。今回は、クエリチューニングの「最後の一手」とも言える、インデックスオンリースキャン（Index Only Scan）という深淵について掘り下げてみたいと思います。
「インデックスを使っているのに、なぜかI/Oが減らない」。そんな苛立ちを感じた経験はありませんか？インデックスを貼るだけでは解決できないボトルネックを、どう突き抜けるか。その鍵は、PostgreSQLの「可視性マップ」にあります。
—
なぜインデックスだけでは足りないのか
まず、基本のおさらいです。通常のインデックススキャン（Index Scan）では、インデックスツリーを辿って対象のポインタ（TID: Tuple Identifier）を見つけ、そこからヒープ（テーブルの実体）へデータをフェッチしに行きます。
この「ヒープへのアクセス」こそが、ランダムI/Oを発生させ、パフォーマンスを大きく損なう要因です。これを回避し、インデックスツリーの情報だけでクエリを完結させるのがインデックスオンリースキャンです。しかし、これが動くためには、「そのデータが本当に正しいのか？」という命題を解決しなければなりません。
Visibility Map（可視性マップ）という静かなる守護者
PostgreSQLには「MVCC（多版同時実行制御）」という仕組みがあります。あるトランザクションから見て、その行が有効かどうかは、ヒープ上の行ヘッダーにある情報（`xmin`, `xmax`など）を確認しないと分かりません。
インデックスのリーフページには、残念ながらトランザクションの状態までは書き込まれていないのです。では、どうやってヒープを見ずにクエリを完結させるのか。ここで登場するのが、各データファイルに付随するVisibility Map (VM) です。
VMは、そのページ内のすべての行が「全トランザクションから見て可視（Visible）」であることを示すビットマップです。もしVMが「このページは全員から見えるよ」と保証していれば、PostgreSQLはヒープを見に行く必要がありません。インデックスの情報だけで「この行は有効だ」と断定できるからです。
なぜ「期待通り」に動かないのか？
ここが現場で一番ハマるポイントです。インデックスオンリースキャンが効かない原因の多くは、以下の2点に集約されます。
1. VMがまだ「クリーン」ではない
データが更新されたばかりだと、VMはまだそのページが「全トランザクションから見える」と確信できていません。VACUUMが走ってVMを更新してくれるまで、PostgreSQLは安全のためにヒープを見に行きます。つまり、書き込み頻度が高いテーブルでは、インデックスオンリースキャンは狙ってもなかなか発動しません。
2. 検索条件にない列を含めていないか
「とりあえず `id` で検索して `name` を取る」というクエリに対し、`id` にだけインデックスを貼ってもダメです。`INCLUDE` 句を使って、検索対象の列をインデックスの付加データとして持たせる必要がある。これは、PostgreSQLのインデックスの「包含」機能を理解しているエンジニアなら、当然の選択肢ですよね。
—
トラブルシューティング：パフォーマンスを極限まで絞り出す
もしあなたが「インデックスオンリースキャンを強制的に効かせたい」という状況なら、以下の手順でデバッグすることをお勧めします。
- `VACUUM ANALYZE` を叩いてみる: もし実行後にIndex Only Scanに切り替わるなら、原因は単にVMが未更新だっただけです。`autovacuum` の設定（特に `autovacuum_vacuum_scale_factor`）が、そのテーブルの更新頻度に対して緩すぎないか見直してください。
- `EXPLAIN (ANALYZE, BUFFERS)` を見る: `Heap Fetches` という値に注目してください。ここが 0 であれば完璧なインデックスオンリースキャンです。もし 0 より大きいなら、それは「インデックスで当たりをつけたものの、結局ヒープまで確認しに行った回数」です。
- INCLUDE句の活用: 複合インデックスを大きくするよりも、`CREATE INDEX … INCLUDE (col_name)` を使って、インデックスツリーのサイズを抑えつつ、必要なデータをリーフページ内に詰め込むのが現代的なアプローチです。
最後に：銀の弾丸ではないということ
最後に一つだけ釘を刺しておきます。インデックスオンリースキャンは非常に強力ですが、インデックスを巨大にしすぎれば、今度はインデックスそのもののI/Oコストが増大し、メモリ（`shared_buffers`）を圧迫します。
「何でもかんでもインデックスオンリースキャンにすればいい」というわけではありません。クエリの実行計画と、システムのI/O特性、そして何よりヒープの状態を理解すること。それこそが、データベースのパフォーマンスを引き出す職人の勘所です。
皆さんのクエリが、今日も効率よくインデックスの中だけで完結することを祈っています。それでは、また。
コメント