【実務・中級編】ハッシュインデックス – PostgreSQL

「ハッシュインデックス？ああ、B-tree一辺倒でやってきた人だと、意外と見落としがちなんだよね」

そう苦笑いしながら、僕が新人の頃に先輩から言われたことを今でも覚えています。

PostgreSQLを触り始めると、どうしても「とりあえずインデックスはB-treeでしょ」となりがちです。確かにB-treeは汎用性が高くて優秀ですが、特定の条件下では、ハッシュインデックスという「玄人好みの選択肢」が劇的なパフォーマンス向上をもたらすことがあるんです。

今日は、そんなハッシュインデックスの正体と、現場で「ここぞ！」という時に使うためのコツを話そうと思います。

—

簡単に言うと、ハッシュインデックスは「ハッシュ値」を計算して、特定のバケットに直接ジャンプする仕組みです。

B-treeが「ツリー構造をたどって範囲を探す」のに対し、ハッシュインデックスは「計算して一発で場所を当てる」。この違いは非常に大きいです。

特に重要なのは、「等価比較（=）」しかできないという点です。範囲検索（`>` や `<`）やソート、`LIKE`検索などは一切受け付けません。まさに「ピンポイントで値を探すためだけに生まれたスペシャリスト」なんですよ。

実は、PostgreSQL 10以前のハッシュインデックスは、クラッシュセーフ（再起動した時にデータが壊れる可能性があった）ではなく、運用で使うにはリスクがありました。

でも、PostgreSQL 10以降、この問題は完全に解消されました。 今やWAL（Write Ahead Log）に書き込まれるようになったので、安心して本番環境で使えるんです。これを機に、もう一度設計の引き出しに入れておくべきだと思いませんか？

例えば、以下のようなケースを想像してみてください。

これらは文字列が長くなりがちですよね。B-treeだと、文字列が長いほどツリーの階層が深くなり、インデックスサイズも肥大化してしまいます。一方で、ハッシュインデックスは計算された固定長のハッシュ値を使うので、インデックス自体が軽量になりやすく、検索効率も極めて安定します。

— ユーザーIDやセッションキーのような、完全一致検索しかしないカラムに
CREATE INDEX idx_user_session_hash ON sessions USING HASH (session_key);

たったこれだけ。「`USING HASH`」を指定するだけで、PostgreSQLが魔法をかけてくれます。

もちろん、万能ではありません。以下のポイントは必ず設計時に頭に入れておいてください。

範囲検索はできない: `WHERE session_key > ‘abc’` といったクエリを書いた瞬間、ハッシュインデックスは無視され、シーケンシャルスキャンが走ります。
インデックスサイズ: B-treeより小さくなることが多いですが、計算コストとのトレードオフです。
マルチカラムインデックスはNG: 複数のカラムを組み合わせたインデックスは作れません。あくまで単一カラム専用です。

僕が設計する時は、こんなルールを自分に課しています。

1. まずはB-treeで作る。これが基本。
2. データ量が膨大になり、特定のカラムの完全一致検索がボトルネックになっていることが明確になった時だけ、ハッシュインデックスへの切り替えを検討する。
3. 「本当に範囲検索の可能性はないか？」を徹底的にビジネスロジックと突き合わせる。

ハッシュインデックスは、いわば「一点突破の武器」です。闇雲に使うのではなく、ここぞという場面で「このデータ特性なら、ハッシュの方が速い」と判断して導入できたら、もう立派なデータベースエンジニアですよ。

—

データベースのパフォーマンスチューニングは、教科書に載っていることの「その先」に面白い答えが隠れています。ぜひ皆さんのプロダクトでも、インデックスの構成を一度見直してみてください。

「おっ、速くなったじゃん」というその瞬間が、この仕事をしていて一番楽しい時ですからね。