こんにちは！データベースの世界へようこそ。
今日は、PostgreSQLの「結合（JOIN）」という、ちょっと難しそうな話をしてみたいと思います。特にその中でも、「ネステッドループ（Nested Loop）」という手法について。
名前だけ聞くと「何かの呪文？」って感じですよね（笑）。でも、実はこれ、私たちの日常生活でも無意識にやっている「すごく馴染み深い」考え方なんですよ。
—
ネステッドループって、結局なんなの？
一言で言うと、「リストAの項目を一つずつ確認しながら、そのたびにリストBの中を探しに行く」というやり方です。
例えば、こんな場面を想像してみてください。
あなたは今、「クラス名簿（テーブルA）」と、「忘れ物リスト（テーブルB）」を持っています。クラス全員の名前の横に、もし忘れ物があればその名前を書き込みたいとしますよね。
あなたはどうやって作業しますか？
1. 名簿の1番目の人を見る。
2. その人の名前が「忘れ物リスト」にあるか、リストを上から順に探す。
3. 2番目の人を見る。
4. また「忘れ物リスト」を最初から探す。
5. ……これを全員分繰り返す。
はい、これこそが「ネステッドループ」の正体です！
外側のリスト（名簿）を1行ずつなぞりながら、そのたびに内側のリスト（忘れ物リスト）をペラペラとめくって探す。まさに「入れ子構造（ネスト）」になったループですよね。
—
どんなときに「最強」なの？
この方法、実はデータ量が少ないときや、検索環境が整っているときはめちゃくちゃ速いんです。
先ほどの例で言えば、もし「忘れ物リスト」がインデックス（辞書のような索引）付きのきれいなノートだったらどうでしょう？
- 「佐藤さん」→ インデックスでパッと開いて「あ、消しゴム忘れてる！」（一瞬）
- 「田中さん」→ インデックスでパッと開いて「なし！」（一瞬）
こんなふうに、「内側のテーブルにインデックスがついている」なら、何万行あっても一瞬で終わります。逆に、インデックスなしで毎回リストを最初から最後までじっくり読んでいたら、日が暮れてしまいますよね。
だから、PostgreSQLも「あ、相手のテーブルにインデックスがあるな。じゃあネステッドループでサクッと片付けよう！」と判断するわけです。
—
注意点：こんな時は「お断り」したくなる
もちろん、万能ではありません。この手法が苦手なパターンもあります。
- 相手のテーブルが巨大で、インデックスもない場合
毎回最初から最後までリストを読み直すことになるので、時間がかかりすぎてしまいます。「それなら、先に両方のリストを並び替えてから照らし合わせたほうが早いよ！」という別の戦略（ハッシュ結合やマージ結合）が選ばれるようになります。
- データが膨大すぎる場合
名簿が100万人分あったら、いくらインデックスがあっても作業は大変ですよね。
—
最後に：データベースとの付き合い方
ネステッドループを理解するコツは、「自分が今、どんなふうにデータを探しているか」をイメージすることです。
「このSQL、なんでこんなに遅いんだろう？」と思ったときは、一度立ち止まって考えてみてください。「あ、これってもし人間が手作業でやったら、何往復もリストを行き来して大変なやつだ！」と気づけたら、もうあなたは立派なデータベースエンジニアの入り口に立っています。
まずは、自分の書いたクエリが「ネステッドループ」で動いているのか、それとも別の手法なのか、`EXPLAIN`コマンドを使って覗いてみることから始めてみましょう。
「へえ、PostgreSQLはこんなふうに考えてたんだ！」とわかると、SQLを書くのがぐっと楽しくなりますよ。
それでは、また次回の記事でお会いしましょう！質問があったら、ぜひ気軽にコメントしてくださいね。
コメント