1. 実行順序の基本的な考え方#

1
-- パターン1: EXISTS
2
FROM users u1
3
LEFT JOIN items i1 ON u1.item_id = i1.item_id
4
WHERE EXISTS (SELECT 1 FROM users u2 WHERE ...)

• 実際の処理：
  1. u1の各行に対して
  2. EXISTSの条件を満たすu2の行を探す（相関サブクエリ）
  3. 条件を満たす行が見つかったらその行を保持

1
-- パターン2: INNER JOIN
2
FROM users u1
3
INNER JOIN items i1 ON u1.item_id = i1.item_id
4
INNER JOIN users u2 ON u1.user_id = u2.user_id
5
WHERE (条件)

• 実際の処理：
  1. データベースエンジンが最適な結合順序を決定
  2. インデックスを使用して効率的に結合を実行
  3. WHERE条件で絞り込み

2. パフォーマンスの違い#

• EXISTSの場合：

  • 相関サブクエリとして動作するため、外部クエリの各行に対してサブクエリを実行
  • ネステッドループのような動作になりやすい

• INNER JOINの場合：

  • データベースエンジンが結合アルゴリズムを選択可能（ハッシュ結合、マージ結合など）
  • 一度の操作で結合を実行できる

3. 最適化の違い#

1
-- EXISTS版
2
SELECT u1.user_id
3
FROM users u1
4
WHERE EXISTS (
5
    SELECT 1
6
    FROM users u2
7
    WHERE u2.user_id = u1.user_id
8
    AND u2.category = 1111
9
)

• 各u1の行に対して、u2をチェック
• インデックスがあっても、繰り返し検索が必要

1
-- INNER JOIN版
2
SELECT u1.user_id
3
FROM users u1
4
INNER JOIN users u2
5
    ON u1.user_id = u2.user_id
6
    AND u2.category = 1111

• データベースエンジンが最適な結合方法を選択可能
• 例：ハッシュテーブルを作成して一度に結合

4. 実際のパフォーマンス比較方法#

1
EXPLAIN ANALYZE
2
SELECT ... /* それぞれのバージョン */

• 実行計画と実際の実行時間を確認
• 使用されるインデックス
• 中間結果のサイズ
• 実際のコスト

5. パフォーマンスに影響する要因#

• テーブルサイズ
• インデックスの有無
• データの分布
• 結合条件の選択性

6. 推奨アプローチ#

1. まず実行計画を確認

1
EXPLAIN FORMAT=JSON
2
SELECT ... /* クエリ */

2. 実際のデータで実行時間を計測

1
SET profiling = 1;
2
SELECT ... /* クエリ */
3
SHOW PROFILES;

3. 結果を比較して最適な方法を選択

重要なポイントは：

• INNER JOINは必ずしも「すべての結合を先に行ってからWHERE句で絞る」わけではありません
• オプティマイザが実行時に最適な順序とアルゴリズムを選択します
• 実際のパフォーマンスは、データ量や分布によって大きく変わる可能性があります

このため、本番環境に近いデータでの実際のテストが重要になります。