答え。

問題の歴史：

EXISTS演算子とIN演算子は、サブクエリに基づいてレコードをフィルタリングするために使用されます。SQLの登場以来、開発者はどちらを選択するかについて悩み、どの方法が速いのか、どのような場合にその使用が好ましいかを理解しようとしてきました。

問題：

主な課題は、外部または内部のテーブルに一致する行のみを取得することです。これは、データセットが大きい場合には常にパフォーマンスにとって重要です。EXISTSとINの選択は、サブクエリの構造、返される値の数と一意性、使用するDBMSによって異なります。

解決策：

サブクエリが少数の一意な値を返す場合、INが通常は効率的です。
一致する行が存在するという事実だけが重要な場合、EXISTSが好ましいです。これは、数千または数百万の行を返す大きなサブクエリに適しています。
NULLに対する特異的な動作や、異なるデータベース管理システムにおける最適化の違いについても考慮する必要があります。

コード例：

-- INの使用
SELECT name FROM students WHERE id IN (SELECT student_id FROM enrollments WHERE course = 'SQL');

-- EXISTSの使用
SELECT name FROM students WHERE EXISTS (SELECT 1 FROM enrollments WHERE enrollments.student_id = students.id AND enrollments.course = 'SQL');

主な特徴：

EXISTSは最初の一致で検索を終了し（ネストされたサブクエリは停止できます）。
INは通常、短いリストで効率的ですが、長い非一意のサブクエリでは遅くなることがあります。
EXISTSはNULLがある場合でも正しく機能しますが、INはサブクエリにNULLが含まれると予想外の動作をすることがあります。

引っかけ問題。

INのサブクエリでNULLに出会った場合、何が起こるか？

ほとんどの人は、INが単にNULLを無視すると考えていますが、NULLが存在すると結果が予測不可能になることがあります。例えば、クエリ：

SELECT id FROM orders WHERE client_id IN (1, NULL, 2);

技術的にはclient_idが1または2でない行は含まれませんが、サブクエリのリストにNULLしか含まれない場合、結果は空になります。

EXISTSとINは完全に互換性のある構文か？

いいえ。EXISTSの使用は通常速く、サブクエリ全体を分析する必要がないためです。さらに、INは複数の列からのサブクエリでは機能しませんが、EXISTSは機能します。これは、WHEREの条件に基づいて比較が行われるからです。例えば：

SELECT col1 FROM t1 WHERE (col1, col2) IN (SELECT col3, col4 FROM t2);

この形式は多くの場合サポートされていませんが、対応するEXISTSはサポートされています。

INはインデックスされたフィールドでEXISTSよりも速く動作することがあるか？

はい、サブクエリが小さく、比較されるフィールドにインデックスがある場合、INが速くなることがあります。しかし、大規模なサンプルやインデックスがない場合は逆です。

一般的なミスとアンチパターン

大量の行を返すサブクエリでINを使用すること。
サブクエリにNULLが存在することによる結果の影響を軽視すること。
クエリプランを分析せずに全てのケースでEXISTSをINに置き換えること。

実生活の例

ネガティブケース

アナリストはINを用いてレポートを作成しましたが、サブクエリが数十万行のNULLを返すことを考慮していませんでした。レポートは数分間動作し、時にデータを失いました。

利点：

ロジックは理解しやすい 欠点：
パフォーマンスの低下
不正確なデータを取得するリスク

ポジティブケース

同じクエリをEXISTSに書き換え、追加の条件を入れ、インデックスを再計算しました。

利点：

迅速な応答
大きなサブクエリとNULLでも正しいフィルタリング 欠点：
より複雑な条件で、実行プランのテストが必要