【業務でよくある状況】
業務システムや帳票作成では、
次のようなSQLを書くことが当たり前のようにあります。
-
伝票データ（検索テーブル）
-
商品・顧客・部署などのマスタテーブル
👉 ほとんどのSELECT文で JOIN が発生する
しかし現場では、
-
とりあえず JOIN している
-
動いているから問題ない
-
遅くなったら考える
というケースが非常に多いのが実情です。
【よくある“業務上の困りごと”】
👉 原因が分からず、調査に時間を取られる
【結論から言うと】
SQLの速度は、
「JOINの書き方」と
「どのテーブルを基点に処理しているか」
で、ほぼ決まります。
JOINは「つなぐ」だけの話ではありません。
処理順序とデータ量をどう扱うか という設計の話です。
【業務視点での重要な考え方】
① 検索テーブルとマスタテーブルは役割が違う
-
検索テーブル
日付・期間・条件で絞り込まれる
（例：伝票、履歴、明細） -
マスタテーブル
件数は比較的少なく、参照される側
（例：商品、顧客、部署）
👉 業務的には当たり前ですが、
SQLではこの違いを意識しない書き方が多い
② 「どれを先に処理するか」が速度を左右する
SQLは、
書いた順番どおりに処理されるわけではありません。
しかし実務では、
-
JOIN条件
-
WHERE句の書き方
-
インデックスの有無
によって、
大量データ × マスタ全件
という無駄な処理が発生することがあります。
【業務的にやってはいけないパターン】
-
まずマスタとJOIN
-
その後で検索条件を指定
👉 データ量が増えるほど、
無駄なJOIN処理が膨れ上がる
初期は問題なくても、
数年後に 「なぜか遅いSQL」 になります。
【業務視点での金言】
金言①
「まず絞る。JOINはその後」
検索テーブルは、
業務条件（日付・期間・状態）で先に絞る
その結果に対して、
必要なマスタをJOINする。
これだけで、
体感レベルで速度が変わることがあります。
金言②
「JOINは“便利な文法”ではなく“コストのかかる処理”」
JOINは、
データが増えるほど 指数的に重くなる 可能性があります。
-
件数が少ないうちは問題なし
-
増えた瞬間に一気に遅くなる
👉 業務が回っているうちに、地雷になる
【技術的な補足（最小限）】
技術的には、
-
インデックス
-
実行計画
-
JOIN順序
といった話になりますが、
業務改善の観点では、
「どのテーブルを、
どの段階でJOINしているか」
を意識するだけで、
SQLの質は大きく変わります。
【まとめ（業務向け）】
-
JOINはほぼすべてのSQLで発生する
-
だからこそ
設計のクセが、そのまま性能差になる -
業務が拡大するほど、
JOINの考え方が効いてくる
「動いているからOK」ではなく、
「将来も耐えられるか」 という視点で
SQLを見ることが重要です。
【参考（技術者向け）】 SQL 高速化の金言
トップページへ
