こんにちは！今日もデータベースの世界へようこそ。
PostgreSQLを触っていると、たまに「実行計画（EXPLAIN）」という言葉を耳にしませんか？「なんだか難しそう……」と画面を閉じたくなった経験、一度はあるかもしれませんね。
でも実はこれ、「美味しいカレーを作るためのレシピ」だと考えると、すごく親しみやすくなるんです。今日は、PostgreSQLが頭の中でどうやってデータを探しているのか、その「実行計画ツリー」の正体を覗いてみましょう！
—
そもそも「実行計画ツリー」って何だろう？
私たちが「このデータが欲しい！」とSQLを投げると、PostgreSQLはすぐさま「よし、それじゃあ効率よく探してくるぞ」と作戦を練ります。その「作戦書」こそが実行計画です。
この作戦書は、単なる箇条書きではありません。「まず冷蔵庫から野菜を出して、次に包丁で切って、その次に鍋で煮込む……」といった、手順の階層構造になっています。これを専門用語で「実行計画ツリー」と呼んでいるだけなんです。
—
料理に例えると、こんな感じ！
例えば、「注文リストの中から、特定の日に売れた商品名を教えて！」というクエリを投げたとしましょう。PostgreSQLは心の中でこんな風に考えています。
1. 【スキャン（材料集め）】：まずは「注文リスト」という巨大な棚から、指定された日の注文票だけをピックアップします。
2. 【結合（下ごしらえ）】：ピックアップした注文票には「商品ID」しか書いていないので、「商品マスタ」という別の棚に行って、名前と照らし合わせます。
3. 【ソート・集計（盛り付け）】：最後に、バラバラな結果を見やすいように並び替えて、完成！
この一つひとつのステップ（スキャン、結合、ソート）が、ツリーの「ノード（枝の節）」なんです。上の階層に行くほど、料理が完成に近づいていくイメージですね。
—
なぜ「ツリー構造」なの？
なぜわざわざツリーにするのか？ それは、「一番効率がいい手順はどれか？」をPostgreSQLが選べるようにするためです。
たとえばカレーを作る時、ジャガイモを先に切るか、玉ねぎを先に切るかは自由ですよね。データベースの世界でも同じです。
- 「商品リストを先に探したほうが早いかな？」
- 「それとも注文リストを全部見たほうがいいかな？」
PostgreSQLはこのツリーの形をあれこれ組み替えて、「これが一番早く、かつ楽に完成する手順だ！」というルートを導き出します。私たちがSQLを書くとき、データベースは裏側でこんなに頭をフル回転させてくれているんですよ。
—
まずは「EXPLAIN」で覗いてみよう
もし興味が湧いたら、普段お使いのクエリの先頭に `EXPLAIN` とつけて実行してみてください。
EXPLAIN SELECT FROM orders WHERE date = ‘2023-10-27’;
すると、PostgreSQLが立てた「作戦」が、階層構造になって表示されるはずです。最初は暗号のように見えるかもしれませんが、「ああ、これが材料を集めてるステップだな」「ここが並び替えてる部分かな？」と、レシピを見比べるような感覚で眺めてみてください。
—
最後に
データベースの世界は、一見すると無機質な数字の羅列に見えます。でも、その裏側には「どうすればユーザーを待たせずに答えを返せるか」という、PostgreSQLの健気な努力が詰まっているんです。
実行計画ツリーは、いわばデータベースとの「対話ツール」です。「ここでもっと時間がかかっているから、インデックスを貼って手伝ってあげようかな？」なんて会話ができるようになると、もっとデータベースが愛おしくなりますよ。
難しく考えすぎず、まずは「今日の晩ごはん」を考えるような気持ちで、実行計画を眺めてみてくださいね。それでは、また次回の記事でお会いしましょう！
コメント