ネステッドループ結合の「美学」と「深淵」：PostgreSQLのオプティマイザとどう付き合うか
PostgreSQLでクエリチューニングをしていると、必ずと言っていいほど「Nested Loop（ネステッドループ）」の挙動に行き当たる。
駆け出しの頃は、Hash JoinやMerge Joinの方が「速そう」に見えて、Nested Loopを避けるようなインデックスの貼り方をしていたものだ。しかし、データベースの深淵を覗けば覗くほど、Nested Loopこそが最もシンプルでありながら、特定の条件下で最強のポテンシャルを発揮する「究極のアルゴリズム」であることがわかってくる。
今日は、この「古典にして最強」の結合手法について、少しエンジニアの視点で深掘りしてみたい。
Nested Loopの内部構造：その計算コストの正体
Nested Loopの挙動は、プログラミング言語の二重ループそのものだ。
1. Outer（外側）テーブルから1行取り出す。
2. その1行をキーにして、Inner（内側）テーブルを検索する。
3. これをOuterテーブルの全行分繰り返す。
この時のコスト計算は、極めてシンプルだ。
- Cost = (Outer Tableの走査コスト) + (Outerの行数 × Innerの検索コスト)
ここで重要なのは、Innerテーブルの検索コストが「インデックスによってどれだけ削れるか」という点に尽きる。もしInnerテーブル側に有効なインデックスが存在し、かつ検索がピンポイント（O(log N)程度）で終わるなら、Nested Loopは他の追随を許さないほど高速に動作する。
なぜ「性能の崖」に落ちるのか
しかし、Nested Loopは「特定の条件」が崩れた瞬間に、性能が急激に劣化する。いわゆる「性能の崖」だ。
よくあるトラブルの典型は、「Outerテーブルの行数が誤って見積もられた時」である。
PostgreSQLのオプティマイザ（プランナ）は、統計情報をもとに「この結合で何行返るか」を予測する。もし統計情報が古く、実際には100万行あるのに「10行」だと見積もられたらどうなるか？プランナは迷わずNested Loopを選択する。
その結果、本来ならHash Joinで一気に処理すべきところが、100万回インデックスを引くという、目も当てられない「オーバーヘッドの洪水」が発生するわけだ。
性能劣化を招く「兆候」を見抜く
トラブルシューティングで私が最初に見るのは、`EXPLAIN ANALYZE`の出力だ。特に以下の点に注目する。
- Actual Loops: 見積もり（Estimated）と実際のループ回数（Actual）に乖離はないか？
- Shared Hit/Read: Inner側のインデックススキャンで、メモリ（Buffer Cache）に乗り切らないI/Oが発生していないか？
もしここが極端に遅いなら、無理にNested Loopに固執せず、`enable_nestloop = off`を一時的に試して、プランナに別の道（Hash Join）を強制的に選ばせてみるのも一つの手だ。そこから「なぜプランナはNested Loopを選んだのか」という逆算を始めるのが、プロの定石というものだろう。
究極のチューニング：Nested Loopを「味方」につけるために
Nested Loopを「悪者」扱いしてはいけない。むしろ、大規模データセットでもNested Loopを正しく選ばせることができれば、メモリ消費を劇的に抑えつつ、レスポンスを安定させることができる。
私たちが意識すべきは以下の3点だ。
1. 統計情報の鮮度: `ANALYZE`は単なる儀式ではない。プランナの判断を支える唯一の地図だ。
2. インデックスの最適化: 単なるカラムのインデックスではなく、結合条件をカバーするインデックスや、`INCLUDE`句を使ったカバリングインデックスを検討する。
3. 相関サブクエリの排除: Nested Loopが不必要に誘発される最大の要因は、実はクエリの書き方そのものにある場合が多い。
最後に
Nested Loopは、PostgreSQLというエンジンの「素直さ」を体現している。
計算機としての理論通りに動き、インデックスの恩恵を最大化し、メモリを極限まで節約する。
もしあなたのクエリがNested Loopで死んでいるなら、それはアルゴリズムの責任ではない。インデックスが足りないか、あるいはデータという名の「現実」と、オプティマイザという名の「地図」がズレているだけだ。
データベースをチューニングするというのは、結局のところ、エンジンと対話して「より良いルート」を教えてあげる作業に他ならない。今日もまた、`EXPLAIN`の海に潜り、そのズレを修正する旅に出るとしよう。
—
あなたの環境でNested Loopが原因でハマった経験、あるいはNested Loopを活用して劇的に高速化した事例があれば、ぜひコメント欄で教えてほしい。エンジニア同士の知見の交換こそが、この業界を面白くするのだから。
コメント