SQL Server INとEXISTSのパフォーマンス

以下のどれがより効率的であるか知りたいですか？

INSQL Serverは結果セットを大きなIFステートメントに変えると私は信じているので、私は常に使用に少し慎重でした。大きな結果セットの場合、これによりパフォーマンスが低下する可能性があります。小さな結果セットの場合、どちらが望ましいかわかりません。大きな結果セットの場合、EXISTSより効率的ではないでしょうか？

WHERE EXISTS (SELECT * FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

対

WHERE bx.BoxID IN (SELECT BoxID FROM Base WHERE [Rank = 2])

EXISTS エンジンがヒットを見つけると、状態が真であることが証明されると、エンジンは見なくなります。

を使用するとIN、さらに処理する前にサブクエリからすべての結果を収集します。

受け入れられた答えは近視眼的であり、その点で質問は少し緩いです：

1）カバリングインデックスが左側にあるか、右側にあるか、または両側にあるかを明示的に述べていない。

2）どちらも入力左側セットと入力右側セットのサイズを考慮しません。
（質問は全体的に大きな結果セットについてのみ言及しています）。

（1）と（2）による大幅なコストの違いがある場合、オプティマイザは「in」と「exists」の間で変換できるほどスマートであると思います。それ以外の場合は、ヒントとしてのみ使用できます（たとえば、右側のシーク可能なインデックス）。

両方のフォームを内部で結合フォームに変換し、結合順序を逆にして、ループ、ハッシュ、またはマージとして実行することができます-推定された行数（左と右）および左、右、または両側のインデックスの存在に基づきます。

SQL Server 2005と2008でいくつかのテストを行いました。他の人が述べたように、EXISTSとINの両方でまったく同じ実際の実行プランが返されます。オプティマイザーは最適です。:)

ただし、EXISTS、IN、およびJOINは、クエリを適切にフレーズしないと、異なる結果を返すことがあります。http：//weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210 .aspx

非常に賛成されたものを含めて、ここには多くの誤解を招く答えがあります（私は彼らの操作が害を意味するとは信じていませんが）。簡単に言えば、これらは同じです。

（T-）SQL言語には多くのキーワードがありますが、結局、ハードウェアで実際に発生するのは、実行クエリプランに見られる操作のみです。

私たちが起動するときに我々が行うリレーショナル（数学理論）の操作[NOT] INおよび[NOT] EXISTS半（使用しているとき抗加入結合ですNOT）。対応するsql-server操作の名前が同じであることは偶然ではありません。言及しINたり、EXISTSどこにでもある操作はありません-（反）セミ結合のみです。このように、論理的に等価であること方法はありませんIN対EXISTS1との唯一の方法があるので選択がパフォーマンスに影響を与える可能性があり、（反）半、実行動作に参加し、その結果を得るためには。

例：

クエリ1（計画）

select * from dt where dt.customer in (select c.code from customer c where c.active=0)

クエリ2（計画）

select * from dt where exists (select 1 from customer c where c.code=dt.customer and c.active=0)

INではなくEXISTSを使用します。以下のリンクを参照してください。

SQL Server：JOIN vs IN vs EXISTS-論理的な違い

返される結果に関して、INはEXISTSまたはJOINと同等に動作するという一般的な誤解があります。これは単に真実ではありません。

IN：指定された値がサブクエリまたはリストのいずれかの値と一致する場合にtrueを返します。

存在：サブクエリに行が含まれている場合はtrueを返します。

結合：結合列の2つの結果セットを結合します。

ブログのクレジット：https : //stackoverflow.com/users/31345/mladen-prajdic

これらの場合、実行プランは通常は同じになりますが、オプティマイザがインデックスなどの他のすべての要素をどのように考慮しているかを確認するまで、実際にはわかりません。

したがって、INはEXISTSと同じではなく、同じ実行プランを生成します。

通常、EXISTSは相関サブクエリで使用されます。つまり、EXISTS内部クエリを外部クエリと結合します。外部クエリ結合と内部クエリ結合を解決してから、それらのwhere句を一致させて両方を結合する必要があるため、結果を生成するためのステップが追加されます。

通常、INは内部クエリと外部クエリを関連付けずに使用されます。これは1つのステップでのみ解決できます（最良のシナリオ）。

このことを考慮：

1. INを使用し、内部クエリの結果が数百万の異なる値の行である場合、EXISTSクエリのパフォーマンスが高い（外部クエリと結合するための適切なインデックスがある）ことを考えると、EXISTSよりも低速になります。

2. EXISTSを使用し、外部クエリとの結合が複雑な場合（実行に時間がかかり、適切なインデックスがない場合）、外部テーブルの行数によってクエリが遅くなり、完了までの推定時間が数日になる場合があります。特定のハードウェアで行数が許容範囲内である場合、またはデータのカーディナリティが正しい場合（たとえば、大きなデータセットのDISTINCT値が少ない場合）、INはEXISTSよりも高速に実行できます。

3. 上記のすべては、各テーブルにかなりの数の行がある場合に注意されます（つまり、CPU処理やキャッシュのRAMしきい値を超えるものを意味します）。

だから答えはそれが依存しています。INまたはEXISTS内に複雑なクエリを記述できますが、経験則として、限られた個別値のセットでINを使用し、個別値の多い行が多い場合はEXISTSを使用するようにしてください。

秘訣は、スキャンする行の数を制限することです。

よろしく、

マリアーノC

を最適化するにはEXISTS、非常にリテラルにします。何かが存在する必要がありますが、実際には、相関サブクエリから返されるデータは必要ありません。ブール条件を評価しているだけです。

そう：

WHERE EXISTS (SELECT TOP 1 1 FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

相関サブクエリはRBARであるため、最初の結果ヒットで条件が真になり、それ以上処理されません。

私の頭の上にあり、正しいことが保証されていません。この場合、2番目の方が速いと思います。

1. 最初に、相関サブクエリにより、サブクエリが各行に対して実行される可能性があります。
2. 2番目の例では、相関がないため、サブクエリは1回だけ実行する必要があります。
3. 2番目の例INでは、一致が見つかるとすぐにが短絡します。