【入門編】結合順序の最適化 – PostgreSQL

こんにちは！日頃からデータベースと向き合っていると、たまに「なんでこのクエリ、こんなに遅いの？」と頭を抱えたくなること、ありますよね。

今日は、PostgreSQLが裏側で一生懸命考えてくれている「テーブルをくっつける順番（結合順序）」のお話をしようと思います。専門用語を並べると難しく聞こえますが、実はこれ、皆さんの日常にある「料理の段取り」と全く同じなんです。

—

想像してみてください。あなたは今、カレーライスを作ろうとしています。

1. 具材を切る（テーブルA）
2. 肉を炒める（テーブルB）
3. 野菜を炒める（テーブルC）
4. 煮込む（テーブルD）

もし、最初に巨大な鍋で「野菜」を煮込んでから「肉」を切っていたら、どうでしょう？効率が悪いですよね。まずは「下準備（絞り込み）」をしてから「混ぜ合わせ（結合）」るのが鉄則です。

データベースの世界でも同じです。PostgreSQLは、何十万件ものデータがあるテーブルを結合する際、「どの順番でくっつければ、一番早く終わるかな？」と、必死に計算（プランニング）しているんです。

結合するテーブルが2〜3個なら、PostgreSQLもすぐに「この順番でやろう！」と正解を見つけられます。でも、これが5個、10個と増えていくと、組み合わせの数は爆発的に増えてしまいます。

実は、全ての組み合わせを完璧に計算しようとすると、計算そのものに膨大な時間がかかってしまい、本末転倒になってしまいます。「献立を考えている間に日が暮れてしまった」という状態ですね。

そこで登場するのが、GEQO（遺伝的クエリ最適化）という仕組みです。

GEQOは、いわば「完璧な正解を捨てる勇気」です。

テーブルの数が多すぎて計算が追いつかないとき、PostgreSQLは「全部を網羅して考えるのはやめよう！遺伝的なアルゴリズムを使って、とりあえずそこそこ良い感じの段取りを見つけよう！」と切り替えます。

要するに、超大人数のパーティー料理を作るときに、厳密なレシピ通りではなく、ベテランシェフの勘で「とりあえずこれで回そう！」と指示を出すようなものですね。

もし皆さんが書いたクエリが遅いと感じたら、以下のことを思い出してみてください。

「絞り込み」を優先する： 料理でいうと、あらかじめ使わない食材を冷蔵庫にしまっておくイメージです。WHERE句でデータをしっかり絞り込んでから結合するように書くと、データベースは迷わなくて済みます。
GEQOに頼りすぎない： 基本的にGEQOは、テーブル数が12個以上など、極端に多いときに動き出します。もし普段のクエリが遅いなら、それはGEQOの問題というより、インデックス（索引）が足りていないか、クエリの書き方が遠回りな可能性が高いです。

—

データベースは、私たちの書いた「注文（クエリ）」を一生懸命解釈して、一番ラクな方法で結果を届けようとしてくれる「優秀なシェフ」です。

たまには、「今日はお料理（クエリ）の段取り、うまくできてたかな？」と、`EXPLAIN`コマンドを使って、PostgreSQLがどんな手順で料理を作ったのか覗いてみるのも面白いですよ。

少しずつ、データベースという料理人と仲良くなっていきましょう！また次回の記事でお会いしましょう。