【テクニカル・上級編】インデックスオンリースキャン – PostgreSQL

究極のクエリ・チューニング：Index Only Scanが「魔法」から「現実」に変わる瞬間

PostgreSQLのチューニングにおいて、誰もが一度は夢見る「Index Only Scan」。テーブルのヒープ領域に一切触れず、インデックスのデータだけでクエリを完結させる。I/Oコストを劇的に抑え、スループットを跳ね上げるこの手法は、まさにパフォーマンスの聖杯とも言える存在です。

しかし、現場で「なぜかIndex Only Scanが効かない」「思ったより速くない」という事態に直面したことはありませんか？今回は、単なる概念論を超えて、PostgreSQLの内部アーキテクチャがこの最適化をどう実現しているのか、そして「Visibility Map」という縁の下の力持ちがなぜ不可欠なのかを深掘りしていきましょう。

—

なぜインデックスだけでは不十分なのか？

そもそも、なぜインデックスを参照するだけではダメなのでしょうか。答えはPostgreSQLのMVCC（多版同時実行制御）アーキテクチャにあります。

インデックスには「どの行がどの位置にあるか」の情報はありますが、「その行が現在のトランザクションから見て可視（Visible）かどうか」というステータスまでは完璧には保持されていません。インデックスだけを見てクエリを返してしまうと、削除された行や、まだコミットされていない他トランザクションの行まで拾ってしまうリスクがあるからです。

そのため、通常はインデックスで位置を特定し、その先のヒープ（テーブル本体）にアクセスして、行のヘッダー情報を確認する必要があります。これが「Index Scan」であり、ヒープへのランダムアクセスがパフォーマンスのボトルネックを生む主因です。

Visibility Mapが切り拓く「ショートカット」

ここで登場するのが Visibility Map（VM） です。これは、各ページ内のすべての行が「全トランザクションから見て可視である」ことを示すビットマップです。

PostgreSQLは、Index Only Scanを実行する際、以下のステップを踏みます。

1. インデックスから対象のインデックスエントリを見つける。
2. そのエントリが指すヒープページの「Visibility Map」を確認する。
3. もしVMで「全行が可視」とマークされていれば、ヒープにアクセスすることなく、そのデータを「有効」と判断して結果を返す。

つまり、Index Only Scanの成否は、インデックスの設計だけでなく、VMのステータスがいかに「クリーン」に保たれているかに依存しているのです。

よくあるトラブルシューティング：なぜ「Scan」のままなのか

「ちゃんとインデックスを貼ったのに、EXPLAINを見るとIndex Scanのままだ」という相談をよく受けます。多くの場合、原因は以下のいずれかです。

頻繁な更新（UPDATE）: 頻繁に更新されるテーブルでは、VMのビットがすぐにクリアされてしまいます。VMのビットは、VACUUMプロセスが「このページはもう古い行がない」と判断したときに初めてセットされるからです。
HOT（Heap Only Tuple）更新の欠如: FILLFACTORの設定が甘く、ページ内に空きがないと、HOT更新が効かずにヒープへのアクセスが必須となります。
統計情報の不整合: プランナが「ヒープにアクセスしたほうが速いかもしれない」と誤認しているケースです。`ANALYZE`を適切に実行し、コスト見積もりの精度を上げる必要があります。

現場で戦うエンジニアへのアドバイス

Index Only Scanを最大限に活かすためには、データベースの運用設計レベルでの工夫が必要です。

Include句の活用: PostgreSQL 11以降であれば、`CREATE INDEX … INCLUDE (…)` を使いましょう。インデックスのキーには含めないが、結果セットには含めたいカラムをペイロードとして持たせることで、Index Only Scanの適用範囲が劇的に広がります。
VACUUM戦略の最適化: VMを有効に保つには、適切な`autovacuum`の設定が不可欠です。`autovacuum_vacuum_scale_factor` を絞り、こまめにページをスキャンさせることで、VMのビットが立ちやすくなります。
無意味なインデックスの排除: 「とりあえず全部インデックスを貼る」のは悪手です。インデックスが増えるほど、書き込み時のオーバーヘッドが増大し、結果としてVMの更新頻度も落ちてしまいます。「このクエリのこのカラムのために」という明確な意図を持ってインデックスを設計してください。

最後に

Index Only Scanは、決して魔法ではありません。それはPostgreSQLというエンジンの内部構造を深く理解し、データのライフサイクルとアクセスのパターンを最適化し続けた結果、得られる「ご褒美」です。

クエリチューニングは、時にパズルのような作業です。しかし、EXPLAINのプランがIndex ScanからIndex Only Scanへと切り替わったときの、あの劇的なレスポンスの向上は、エンジニアにとって何物にも代えがたい快感ではないでしょうか。

あなたのデータベースにも、まだ隠れた「最適化の余地」が眠っているはずです。ぜひ、Visibility Mapの挙動を意識しながら、もう一度クエリと向き合ってみてください。