【テクニカル・上級編】式インデックス（Expression Indexes） – PostgreSQL

「なぜその検索は遅いのか？」— 式インデックスが救う、泥沼化したクエリの最適化術

PostgreSQLを長年触っていると、必ずと言っていいほど直面する壁があります。それは、「インデックスを貼っているのに、フルスキャンが走る」という現象です。

開発者が良かれと思って追加したインデックスが、実行計画（EXPLAIN）を見ると虚しく無視されている。その理由の多くは、WHERE句でカラムに対して関数を適用していることに起因します。

`WHERE LOWER(email) = ‘example@gmail.com’`

このクエリを投げた瞬間、PostgreSQLのオプティマイザは、「ああ、これはインデックスをそのまま使えないな」と判断します。B-treeのインデックス構造は、あくまでカラムに格納された「値」の並び順に基づいて構築されているからです。`LOWER()`という変換処理が加わった途端、既存のインデックスは無力化します。

ここで多くのエンジニアが「カラムを正規化して別カラムに保存する」といった複雑な設計変更に走りがちですが、そんな時こそ、PostgreSQLの真骨頂である「式インデックス（Expression Indexes）」の出番です。

内部構造から読み解く式インデックスの「正体」

式インデックスを理解するには、少しだけPostgreSQLのインデックスの裏側を覗く必要があります。

PostgreSQLにおけるインデックスとは、単なる「テーブルのコピー」ではなく、キーとなる値と、それに対応するタプル（行）のTID（Tuple Identifier）を紐付けた独立したデータ構造です。

式インデックスを作成する際、PostgreSQLはインデックス構築時に式の結果を計算し、その結果をインデックスの「キー値」として保存します。

CREATE INDEX idx_users_lower_email ON users (LOWER(email));

このコマンドを打った瞬間、DBはテーブルをスキャンし、`LOWER(email)`の計算結果をB-treeに格納します。クエリが実行される際、オプティマイザはWHERE句の式とインデックス定義の式が一致しているかを即座にチェックします。一致すれば、計算済みのインデックスキーを使って高速な検索（Index Scan）へと誘導するわけです。

非常にシンプルですが、ここには「計算コストを挿入時（あるいは更新時）に先払いする」という、パフォーマンスエンジニアリングの極めて合理的な思想が流れています。

パフォーマンスチューニングの現場で気をつけるべき「罠」

式インデックスは魔法の杖ではありません。実戦投入する際には、いくつか注意すべき「落とし穴」があります。

計算コストと更新負荷のトレードオフ

式インデックスは、データが挿入・更新されるたびに再計算が走ります。もし式が`MD5()`や複雑なJSONB操作などの重い関数であれば、書き込み負荷（Write amplification）が無視できないレベルまで跳ね上がります。読み取りと書き込み、どちらを優先すべきかを慎重に見極める必要があります。

不一致によるインデックス無視

式インデックスは「完全一致」を求めます。例えば、`LOWER(email)`でインデックスを作ったのに、クエリ側で`UPPER(email)`と書いてしまえば、インデックスは使われません。式は1ビットの狂いもなく記述を合わせる必要があります。

統計情報の扱い

式インデックスを利用する場合、PostgreSQLがその式の結果分布を正しく把握できているかを確認してください。もしインデックスの選択率が不正確だと、オプティマイザが「インデックスを使うよりフルスキャンの方が速い」と誤った判断を下すことがあります。その場合は、`ANALYZE`を手動で実行し、統計情報を最新化する習慣をつけておきましょう。

実践：JSONBとの組み合わせが最強の武器になる

現代のPostgreSQL運用において、JSONB型を多用するケースは多いはずです。ここで式インデックスが輝く瞬間があります。

例えば、大量のログデータから特定のステータスコードを抽出するようなクエリ。

— よくあるアンチパターン
WHERE (data->>’status’)::int = 200

これも式インデックスを使えば劇的に変わります。

CREATE INDEX idx_logs_status ON logs (( (data->>’status’)::int ));

JSONBのネスト構造が深くなればなるほど、クエリ実行時のパースコストは累積します。式インデックスで型変換まで終わらせておくことで、クエリ実行時は単なる値の等価比較にまで昇華させることができます。これは大規模なログ分析系クエリにおいて、数秒のレスポンスを数ミリ秒に短縮するポテンシャルを秘めています。

最後に：エンジニアとしての矜持

式インデックスを使いこなすということは、自分が書いたクエリが「DBの内部でどう処理されているのか」を想像できるということに他なりません。

「なぜ遅いのか」をDBのせいにせず、内部アーキテクチャの視点から解決策を導き出す。その積み重ねが、堅牢でスケーラブルなシステムを支えるエンジニアの職人芸なのだと、私は信じています。

皆さんのデータベースに潜む「隠れたコスト」を、ぜひ式インデックスで削ぎ落としてみてください。その瞬間に感じるレスポンスの軽快さは、何にも代えがたいエンジニアとしての快感であるはずです。