なぜ、すべての行にインデックスを貼るのか？――部分インデックスがもたらす「静かなる革命」
PostgreSQLを触り始めてしばらく経つと、誰もが一度は「インデックスの肥大化」という壁にぶつかります。テーブルが数億行を超え、インデックスサイズが物理メモリを圧迫し始めると、パフォーマンスのチューニングは単なる「クエリの最適化」から「I/Oとメモリの生存戦略」へと変わります。
そんな時、我々エンジニアの強力な味方となるのが部分インデックス（Partial Indexes）です。
一見、単なる `WHERE` 句付きのインデックスに見えますが、こいつを使いこなせるかどうかで、大規模DBの運用負荷は劇的に変わります。今日は、教科書的な説明は抜きにして、現場での「実戦的な勘所」を深掘りしてみましょう。
—
インデックスの「断捨離」という発想
部分インデックスの最大の魅力は、ストレージの節約――だけではありません。もっと重要なのは、インデックスの「ノイズ」を消し去ることで、検索効率と更新コストを最適化できる点です。
例えば、「未処理の注文だけを抽出する」というクエリが頻発するシステムで、テーブル全体にインデックスを貼るのは、往々にして無駄が多い。処理済みデータが圧倒的に多い場合、そのインデックスは、メモリの無駄遣いであるだけでなく、テーブル更新のたびに不要なインデックス更新コストを強いる「負債」になり得ます。
CREATE INDEX idx_orders_pending
ON orders (created_at)
WHERE status = ‘pending’;
この一行だけで、B-treeの深さは劇的に浅くなり、`VACUUM` の負荷も軽減されます。スキャン対象が絞り込まれることで、インデックスのページヒット率が向上し、結果としてL1/L2キャッシュの汚染も最小限に抑えられる。これが、私が部分インデックスを好む一番の理由です。
—
内部アーキテクチャから見た「正しさ」
PostgreSQLのエンジンが部分インデックスをどう扱っているか、少しだけ深掘りしましょう。
PostgreSQLは、クエリの `WHERE` 句とインデックス作成時の `WHERE` 句を照合し、「そのインデックスがクエリの結果を包含できるか」という証明（Implies）を行います。つまり、オプティマイザは単にインデックスの定義を眺めるだけでなく、論理的にクエリを充足しているかを判定しているわけです。
ここで注意すべきなのが、統計情報の乖離です。
部分インデックスを使うと、`pg_stats` などの統計情報もその条件に従います。もし、特定の条件のデータのみが極端に分布が偏っている場合、オプティマイザが誤ったコスト算出を行うことがあります。
- トラブルシューティングのヒント:
部分インデックスを利用しているのに実行計画がフルスキャンを選択する場合、`ANALYZE` を実行して統計情報を最新にするのは基本中の基本ですが、それでも直らないときは、`CREATE STATISTICS` を検討してください。部分インデックスとマルチカラム統計の組み合わせは、現代のPostgreSQLチューニングにおける「切り札」です。
—
実践的な「アンチパターン」と向き合う
部分インデックスを使い始めると、必ず一度はやりたくなるミスがあります。それは「インデックスの条件が、クエリと微妙に噛み合わないこと」です。
たとえば、`WHERE status = ‘pending’` でインデックスを作ったのに、クエリ側で `WHERE status = ‘pending’ OR status = ‘retrying’` と書けば、当然インデックスは使われません。
「なぜインデックスが効かないんだ？」とログを眺める前に、まずは `EXPLAIN` でインデックスの条件が「推論可能か」を冷静に自問してください。
また、更新頻度の高いカラムを部分インデックスの条件にする場合は注意が必要です。値が更新されて「部分インデックスの対象外」になった際、PostgreSQLはインデックスからエントリを削除します。これが頻発すると、インデックスのフラグメンテーションが進行しやすくなります。この場合は、そもそもデータ設計（ステータス管理）を見直すべきシグナルかもしれません。
—
最後のアドバイス：インデックスは「引き算」である
多くのエンジニアが「どのカラムにインデックスを貼るか」を考えますが、熟練者は「どこまでインデックスを削ぎ落とせるか」を考えます。
部分インデックスは、単なる機能ではなく「このデータはここさえ見ればいい」という、我々エンジニアからデータベースへの「宣言」です。
皆さんのデータベースに眠っている、数百万行の「死んだインデックス」はありませんか？
もしあれば、それは部分インデックスで救えるかもしれません。ストレージを解放し、I/Oを最適化し、そして何より、システムに「余裕」を持たせてあげてください。
チューニングとは、突き詰めれば「不要なものをいかに排除するか」という作業なのですから。
コメント