1- 以下のコマンドのパフォーマンスの違いは何ですか?
... Where ID in (1,2,3)
... where ID = 1 OR ID = 2 OR ID = 3
2- 以下のコマンドのパフォーマンスの違い (条件の優先度) はどこですか?
... where Condition1 and condition2 -> ... where condition2 and condition1
... where Condition1 OR condition2 -> ... where condition2 OR condition1
以下の 2 つのタイプに違いはありません。とにかく、実行時にDBエンジンはIN句をORスタックにフラット化します。に拡張IN(1,2,3)されますcol = 1 OR col = 2 OR col = 3
... Where ID in (1,2,3)
... where ID = 1 OR ID = 2 OR ID = 3
性能に大きな差はないと思います。実行計画を見ると、SQL Server はデータの読み込みステップにフィルタリングを埋め込んでいます。これは、データがディスクから読み取られ、ディスク ページにロードされるときに発生します。一方を他方より高速にするために数サイクルを費やしても、I/O の気まぐれに比べて基本的には何の効果もありません。
「in」演算子の典型的な実装の 1 つは、小さなハッシュ テーブルとして実装することです。3 つの要素の場合、これは逐次比較よりも簡単に遅くなる可能性があります。ただし、より多くの比較を行うには、「in」アプローチの方が高速です。ビルトインのハードウェア比較は非常に高速であるため、これは数値の場合に特に当てはまります。ただし、コンパイラは "in" リストの内容を認識しているため、データベース設計者が最適化に価値があると判断した場合は、逐次比較を選択できます。しかし、彼らがそう思うとは思えません。
アーロンのコメントに返信します。私の信念は、IN が返す可能性のある 2 つのエラーに基づいています。
エラー 8623: クエリ プロセッサが内部リソースを使い果たしたため、クエリ プランを作成できませんでした。これはまれなイベントであり、非常に複雑なクエリ、または非常に多数のテーブルまたはパーティションを参照するクエリでのみ予想されます。クエリを簡略化してください。このメッセージを誤って受け取ったと思われる場合は、詳細についてカスタマー サポート サービスにお問い合わせください。
エラー 8632: 内部エラー: 式サービスの制限に達しました。クエリ内の潜在的に複雑な式を探して、単純化してみてください。
(http://msdn.microsoft.com/en-us/library/ms177682.aspx)
私は、WHERE 句の論理式に関するこれらのエラーに精通していません。したがって、基になる実装がハッシュ テーブルを使用しているという、おそらく性急な仮定を行いました。