ネステッドループ結合：その「単純さ」に隠された、PostgreSQLの美学
PostgreSQLのクエリプランナーが叩き出す実行計画。`Nested Loop`という文字を目にしたとき、皆さんは何を思いますか？
「ああ、最悪のケースか」と思うか、それとも「いや、これは適材適所の勝利だ」と考えるか。経験豊富なエンジニアほど、この単純な結合アルゴリズムがいかに奥深く、そして時として諸刃の剣になるかを理解しているはずです。
今日は、PostgreSQLのコアアーキテクチャの視点から、Nested Loopの「本質」を深掘りしてみましょう。
—
ネステッドループ結合の「実態」を紐解く
Nested Loopの本質は、極めて原始的です。外側（Outer）テーブルから1行取り出し、それに対応する行を内側（Inner）テーブルで探す。これを外側の全行に対して繰り返す。
計算量で言えば $O(M \times N)$。これだけ聞くと効率が悪そうに見えますが、PostgreSQLのエンジンはここを非常に賢く制御しています。
なぜNested Loopは「選ばれる」のか
プランナーがNested Loopを選択する背景には、主に2つのシナリオがあります。
1. インデックスの活用: 内側テーブルに適切なインデックス（特にB-tree）が張られており、検索コストが極めて低い場合。
2. 圧倒的な絞り込み: 外側テーブルから抽出される行数が極端に少ない場合（例えば、主キーによる1行限定の検索など）。
このとき、Hash JoinやMerge Joinのような「準備コスト（メモリ確保やソート）」を払うよりも、ループで確実に1行ずつ叩く方が、トータルコストは圧倒的に低くなるのです。
—
現場で遭遇する「Nested Loop地獄」の正体
しかし、我々エンジニアがトラブルシューティングで頭を抱えるのは、往々にしてこの「Nested Loopの暴走」です。
1. 統計情報の「嘘」
プランナーは常に統計情報を見て判断します。しかし、実際のデータの分布と統計情報が乖離していると、プランナーは「外側テーブルは数行しか返さないはずだ」と誤認します。
結果として、実際には数万行返るクエリに対してNested Loopを選択してしまい、内側テーブルへのインデックススキャンが膨大なオーバーヘッドを生む……これが現場で最もよく見る悪夢の一つです。
2. 内側テーブルの「ランダムアクセス」
Nested Loopの最大の弱点は、内側テーブルに対するランダムI/Oの多発です。内側テーブルへの検索がディスクI/Oに直結する場合、ループ回数が数千を超えるだけで、クエリは一気に失速します。
もし皆さんの環境でNested Loopが遅いと感じたら、まずは `EXPLAIN (ANALYZE, BUFFERS)` を見てください。共有バッファの読み取り回数（Shared Hit/Read）が異常に増えていないかを確認するのが定石です。
—
パフォーマンスチューニングへの提言
Nested Loopと上手に付き合うために、我々ができることはいくつかあります。
- 相関サブクエリの再考: `EXISTS` や `IN` 句でNested Loopが多用される場合、それらが本当に論理的に正しいか見直してみてください。時として、`JOIN` に書き換えるだけでプランナーの選択肢が広がり、Hash Joinが選ばれるようになります。
- 統計情報の鮮度: `ANALYZE` は単なるルーチンワークではありません。特にヒストグラムの精度が落ちていると、プランナーは悲しいほどに無能になります。`ALTER TABLE … SET STATISTICS` で、偏りのあるカラムの解像度を上げてやるのも、熟練エンジニアの嗜みです。
- インデックスの最適化: Nested Loopを前提とするなら、カバリングインデックス（Index-Only Scanを狙う）の作成を検討してください。内側テーブルの検索がメモリ（インデックス）だけで完結すれば、Nested Loopは最強の武器に変わります。
—
最後に：アルゴリズムを「信じすぎない」勇気
Nested Loopは、PostgreSQLという巨大な機械の中で、最も小さく、最も愚直な歯車です。しかし、この小さな歯車が正しく噛み合っているとき、PostgreSQLは驚くほどのレスポンスを返します。
トラブルが発生したとき、つい「Hash Joinに強制したい」と `enable_nestloop = off` をいじりたくなる衝動に駆られるかもしれません。しかし、それは対症療法に過ぎません。なぜプランナーがその選択をしたのか、背後にあるデータの特性とインデックスの構造を想像してみてください。
データベースエンジニアの仕事とは、プランナーと対話し、彼らが正しい判断を下せるように「情報の道筋」を作ってやることなのです。
今日もどこかで、Nested Loopが最速の選択肢として静かに働いていることを願っています。それでは、また。
コメント