「ネステッドループ結合」を使いこなす：PostgreSQLの性能を左右する一番身近なアルゴリズム
やあ。データベースのパフォーマンスチューニングに頭を悩ませているなら、まずは「ネステッドループ結合（Nested Loop Join）」と仲良くなることから始めようか。
PostgreSQLの実行計画（`EXPLAIN`）を見ていると、必ずと言っていいほど目にするのがこの結合アルゴリズムだ。「なんだ、一番原始的なやり方か」と侮るなかれ。実は、こいつを制する者がPostgreSQLのクエリチューニングを制すると言っても過言じゃないんだ。
今日は、現場で後輩によく話す「ネステッドループの本質」を解説するよ。
—
ネステッドループ結合の正体
名前の通り、二重ループを回すような仕組みだ。
1. 外側のテーブル（Outer Table / Driving Table）から1行取り出す。
2. その1行をキーにして、内側のテーブル（Inner Table）を検索する。
3. これを外側のテーブルの行が尽きるまで繰り返す。
単純だよね。でも、この単純さが「最強の武器」にも「最悪の足かせ」にもなる。
なぜ「小規模な結合」に適しているのか？
内側のテーブルを検索する際、もしそこにインデックスが貼られていれば、非常に高速にピンポイントでデータを見つけられる。これがネステッドループの真骨頂だ。逆に言えば、内側のテーブルが巨大でインデックスが効かないような状況だと、データベースは地獄のようなスキャンを繰り返すことになる。
—
実践的な使用例：こんな時に使え！
例えば、ECサイトで「特定の注文（Orders）に紐づく注文明細（Order_Items）を取得する」ようなケースを考えてみよう。
SELECT
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
WHERE o.user_id = 12345;
このとき、PostgreSQLは賢いから、こんな判断をするはずだ。
- `o.user_id` にインデックスがあれば、まずは数件の注文（`orders`）を特定する。
- 特定した数件の注文それぞれに対して、`oi.order_id` のインデックスを使って `order_items` を引く。
これはネステッドループにとって「理想的な環境」だ。外側のテーブルが絞り込まれていて、内側のテーブルにインデックスが効いている。このパターンなら、ハッシュ結合（Hash Join）なんかよりも遥かに低コストで結果を返せるんだ。
—
注意：ネステッドループが「悪夢」に変わる瞬間
逆に、パフォーマンスが急降下するのはこんな時だ。
- 結合キーにインデックスがない: 内側のテーブルを毎回フルスキャンすることになる。「行数 × 全データ量」の計算コストがかかる。想像するだけで恐ろしいよね。
- 外側のテーブルが巨大: 100万行のデータに対してネステッドループを回せば、100万回インデックスを引くことになる。この場合、PostgreSQLはハッシュ結合などの別の手法を選びたがるはずだ。
もし実行計画を見て、「Nested Loop」が使われているのにクエリが遅いなら、まずは内側のテーブルの結合キーにインデックスがあるかを確認してほしい。これが第一歩だ。
—
チューニングのための小技：SET enable_nestloop
デバッグ中に「この結合方法を変えたらどうなるんだろう？」と試したくなることがあるよね。そんなときは、一時的にセッション単位で制限をかけてみるのも手だ。
— 一時的にネステッドループを禁止してみる
SET enable_nestloop = off;
— 実行計画を確認
EXPLAIN ANALYZE SELECT … ;
これを使って、オプティマイザがなぜネステッドループを選んだのかを比較・検証する。現場ではよくやる「裏技」的なテクニックだ。ただ、本番環境でこれを設定するのは御法度だから気をつけよう。あくまで実験用だ。
—
先輩からのアドバイス
データベースエンジニアとして一つ覚えておいてほしいのは、「アルゴリズムに良し悪しはない」ということだ。
「ハッシュ結合が速い」「マージ結合が効率的」なんて言う人もいるけれど、それはその時のデータ量とインデックス次第なんだ。ネステッドループは、正しく使えば数ミリ秒で終わるクエリを、使い方を間違えればサーバーをダウンさせる原因にもなる。
まずは `EXPLAIN` を見て、PostgreSQLがなぜその選択をしたのかを想像してみてほしい。それがチューニングの一番の近道だし、技術力も一番伸びるはずだよ。
また分からないことがあったら、いつでも聞いてくれ。一緒に最高のクエリを追求しようぜ！
コメント