こんにちは！データベースの世界へようこそ。
普段、何気なく使っているデータベースですが、SQLを投げたときに裏側で何が起きているのか、ちょっと気になったことはありませんか？今日は、PostgreSQLが誇る「結合（JOIN）」の仕組みの中でも、一番シンプルで、かつ奥が深い「ネステッドループ結合（Nested Loop Join）」についてお話しします。
専門用語の羅列は置いておいて、まずは日常の風景からイメージしてみましょう。
—
1. そもそも「結合」って何をしているの？
データベースで「結合」をするというのは、簡単に言えば「2つの名簿を突き合わせて、共通点を探す作業」です。
例えば、あなたがカフェの店長だと想像してください。
- 名簿A（注文リスト）： 今日注文が入ったメニューのリスト
- 名簿B（レシピカード）： 各メニューの作り方が書かれたレシピ集
「注文リスト」に書かれたメニューを一つずつ手に取り、「レシピカード」の中から該当するものを探して、作り方を確認する。これがデータベースで言うところの「結合」です。
2. ネステッドループ結合は「総当たり戦」
さて、この作業をどうやって進めるのが一番効率的でしょうか？
ネステッドループ結合は、もっとも直感的で、かつ泥臭い（でも確実な）方法をとります。
具体的な手順
1. 注文リスト（外側）から、一番上の注文を一つ手に取ります。
2. そのメニューが何なのかを確認し、レシピカード（内側）の山を最初から最後まで順番にめくって、一致するカードを探します。
3. 見つかったら「注文リストの2番目のメニュー」へ移り、また最初からレシピカードの山をめくります。
4. これを注文リストの最後まで繰り返します。
そう、これがネステッドループ（入れ子になったループ）です。
外側のリストを回しながら、そのたびに内側のリストを全探索する。まさに「総当たり」ですよね。
3. この方法の「良いところ」と「弱点」
初心者の方からよく「全部毎回探し直すなんて、非効率じゃないの？」という鋭い質問をいただきます。その通り！そこがこのアルゴリズムの性格を決定づけています。
ネステッドループが輝くとき
- 外側のリストがとても短いとき： 注文が3つしかないなら、レシピの山を3回めくるのは大した手間じゃありませんよね。
- 内側のリストに「インデックス（見出し）」がついているとき： もしレシピカードが「あいうえお順」に並んでいたらどうでしょう？いちいち全部めくらなくても、パッと見つけられますよね。PostgreSQLも同じで、インデックスがあればこの結合は爆速になります。
ちょっと苦手なとき
- 両方のリストが膨大で、かつ整理されていないとき： 数万件の注文に対して、数万件のレシピを毎回最初から探していたら、お店が閉店してしまいます。この場合は、他の賢い結合アルゴリズム（ハッシュ結合など）の出番になります。
4. 最後に：データベースの「優しさ」を理解する
PostgreSQLというデータベースエンジンは、実はとっても空気が読める存在です。
私たちが「この2つのテーブルをくっつけて！」と命令したとき、PostgreSQLは「よし、データが少ないからネステッドループでサクッと終わらせよう」とか「データが多すぎるから、別の方法を考えよう」といった具合に、裏でめちゃくちゃ頭を回転させています。
もしあなたがクエリを書いていて「なんだか遅いな？」と感じたら、それはPostgreSQLが「ネステッドループで頑張っているけれど、インデックスがないからレシピを全検索しなきゃいけなくて大変なんだ！」と悲鳴を上げているサインかもしれません。
—
いかがでしたか？「ネステッドループ」という名前は難しそうですが、要は「片方を手に持って、もう片方を一つずつチェックする」という、私たちの日常的な作業と全く同じなんです。
こうして仕組みを知っておくと、普段のデータベース操作が少しだけ愛おしく感じませんか？ぜひ、次回の開発でSQLを書くときには、頭の中で「今、注文リストをめくっているな…」なんて想像してみてくださいね。
それでは、また次回の記事でお会いしましょう！
コメント