回答:
SQLは宣言型言語であることを認識することが重要です。作成したSELECT
クエリは、返される論理結果を指定します。これらの結果を返すための効率的な物理戦略を決定するのは、データベースエンジン、特にクエリオプティマイザー次第です。
最終的な物理実行計画は、オプティマイザーの推論能力、問題に費やす準備時間、適切なアクセス方法(主にインデックスとマテリアライズドビュー)の可用性、代表的な統計情報、および特定のコードパスに依存しますクエリ仕様は、最適化コードを使用します。
一般に、データベース設計がリレーショナルであり、適切なアクセス方法と正確な統計情報を提供し、クエリが適切に記述されている場合、オプティマイザーは通常、書かれた形式についてあまり心配することなく、合理的な物理実行戦略を見つけますクエリ仕様が多すぎます。
異なる(ただし意味的には同一の)構文を使用して同じロジック要件を表現することが物理的な実行計画に影響する場合が常にありますが、それは二次的な関心事です。繰り返しますが、一般的には、上記のすべての基本事項が網羅された後、ランタイム特性が受け入れられない場合にのみ、クエリの表現を変えることを検討してください。
極端な場合、WHERE
(質問のように)単純な接続句の述語の記述された順序が、測定可能な方法で物理的な実行計画に影響を与えることはまれです。要するに、これはあなたが心配する時間を費やすべきものではありません。データベース設計、インデックス、統計情報を最初に入手してください。
(最終的に!)質問に直接答えるために、余分な冗長条件を追加するとパフォーマンスが向上する可能性がありますが、より効率的なアクセス方法の使用が有効になっている場合のみです(たとえば、(BitField、VarcharField)にインデックスのみがある場合)。(VarcharField)にすでにインデックスがある場合、オーバーヘッドのみが追加されます。
実装の詳細として、いや、SQL Serverはデータ型や明らかな計算の複雑さに応じて比較のコストを考慮しません。実際、スカラー演算のコストはほとんどかかりませんが、それはまったく別のトピックにつながります。
関連する質問:
WHERE
SQL Server 2008および定数式の条件および条件の順序の論理演算子OR AND
パフォーマンスに影響するビット単位の演算子
奇妙なSQLステートメントの動作