やあ、今日もデータベースと格闘してるかい？
PostgreSQLを触っていると、たまに「なんでこんなにクエリが遅いんだ！」って頭を抱えたくなる夜があるよね。そんな時、`EXPLAIN ANALYZE` を叩いて「Hash Join」の文字を見つけた経験はないかな？
教科書には「ハッシュ結合はメモリ上でハッシュテーブルを作る手法」なんて小難しいことが書いてあるけど、現場の実務では、もう少し「肌感覚」で理解しておくとチューニングの精度が劇的に変わるんだ。今日は、このハッシュ結合の正体と、現場でどう付き合うべきかについて、少し深掘りしてみよう。
そもそも「ハッシュ結合」って何をしているのか
簡単に言うと、ハッシュ結合は「片方のテーブルを辞書（ハッシュテーブル）にして、もう片方のテーブルをペラペラめくりながら突き合わせる」ようなイメージだ。
1. ビルドフェーズ（構築）: 小さい方のテーブル（内側）を読み込み、結合キーをハッシュ関数に放り込んで、メモリ上に「ハッシュテーブル」を作る。
2. プローブフェーズ（探索）: 大きい方のテーブル（外側）をスキャンしながら、キーを同じハッシュ関数で変換し、作ったばかりの辞書に「このキー、ある？」と高速で問い合わせる。
ネステッドループ（入れ子ループ）が「地道な総当たり戦」だとしたら、ハッシュ結合は「効率的な索引引き」に近い。だから、データ量が多い時の等価結合（`=`）では、こいつが最強の武器になるんだ。
現場で意識すべき「ワークメモリ」の正体
ここで一つ、実務で絶対に覚えておいてほしいパラメータがある。そう、`work_mem` だ。
ハッシュ結合は、構築したハッシュテーブルをメモリ上に載せる必要がある。もしテーブルが大きすぎてメモリに収まらないと、PostgreSQLはディスクに書き出し（スピル）を始めるんだ。これが始まると、パフォーマンスは一気にガタ落ちする。
— 実行計画でこんな表示が出たら要注意
-> Hash (cost=… rows=… width=…)
Buckets: 1024 Batches: 1 Memory Usage: 32kB
この `Memory Usage` と `Batches` に注目してほしい。`Batches` が 1 より大きくなっていたら、メモリ不足でディスクに逃げている証拠だ。そんな時は `work_mem` を調整するか、そもそもインデックスを見直す必要がある。
具体的なコード例：ここがチューニングの勘所
例えば、数百万件ある `orders` テーブルと、数千件の `users` テーブルを結合する場面を考えてみよう。
SELECT u.name, o.order_date
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE u.status = ‘active’;
この時、PostgreSQLは賢いから自動的に `users` をハッシュテーブルとして構築してくれるはずだ。でも、もしここが遅いなら、以下のポイントをチェックしてみて。
1. 結合キーの型は一致しているか？: 型が違うと暗黙の型変換が走り、インデックスが効かないどころかハッシュ関数の計算コストまで無駄に増える。
2. 統計情報は最新か？: `ANALYZE` をサボっていると、オプティマイザが「どっちが小さいテーブルか」を読み違えて、とんでもない非効率な結合プランを立てることがある。
3. 不要なカラムをSELECTしていないか？: ハッシュテーブルに詰め込む情報が多ければ多いほどメモリを食う。`SELECT ` は百害あって一利なしだ。
先輩からのアドバイス：過信は禁物
最後に一つだけ。ハッシュ結合は万能じゃない。
「とりあえずハッシュ結合になれば速い」なんて考えていると、思わぬ罠にハマる。例えば、結合対象のデータが極端に偏っていたり、メモリがカツカツの環境で同時実行数が多かったりすると、ハッシュ結合のオーバーヘッドが逆に足かせになることもあるんだ。
`EXPLAIN` を眺めるときは、ただプランを見るんじゃなくて、「なぜオプティマイザはこのプランを選んだのか？」という背景まで想像してみてほしい。それができるようになると、もう君は一人前のデータベースエンジニアだ。
データベースは、正直な相棒だよ。こちらが仕組みを理解して丁寧に扱えば、必ず最高のパフォーマンスで応えてくれる。
さて、そろそろ次のクエリの最適化に戻ろうか。また何か詰まったら、いつでも聞きに来てくれよな！
コメント