"計画を説明していません"。以下のうちどれが効率的かを教えてください。OracleのSQLパフォーマンス・チューニング多くのORとIN（）
オプション1：
select ...
from VIEW_ABC
where STRING_COL = 'AA'
OR STRING_COL = 'BB'
OR STRING_COL = 'BB'
OR ...
OR STRING_COL = 'ZZ'
オプション2：
select ...
from VIEW_ABC
where STRING_COL IN ('AA','BB',...,'ZZ')
私は、オプティマイザが同じ両方のバージョンを扱いますと仮定します。 INは、実際には複数のORステートメントの構文略語です。
これは、同様の質問です： IN vs OR of Oracle, which faster?
OMGポニーによって与えられた答えを見て、彼はINがORより最適化されていることを示唆しています。
この質問もあります： IN vs OR in the SQL WHERE Clause
それ以外のデータベース固有のものですが、それは、Oracleの観点からいくつかの良い答えを持っています。
価値があるのであれば、INの使用ははるかに読みやすく、したがって長期的にはサポートしやすくなります。それだけであなたの選択を揺るがすかもしれません。特に、オラクルのオプティマイザが（私が疑うように）それらを同じ方法で扱うならば。
ただし、値のリストが非常に大きい場合は、結果を取得するための方法がまったく異なることがあります。
オプティマイザは引き続きString_Col列にオプティマイザが存在する場合はそれを使用してインデックスを作成します。 構文解析に役立つ適切なサイズのSQLを維持するために、Oracleで250-500の文字列を解析するのではなく、temp表またはpl/sql表に可能な値をすべて入れ、このように - PL /をsql_tableから
セレクト/ * +命じUSE_NL（x）は、*/* 、view_abc X x.string_col = PL/sql_table.value
ヒントと一時テーブルは、他の多くの潜在的な問題を追加する可能性があります。これで、オプティマイザは別のテーブルを理解する必要があります。余分なテーブルのオーバーヘッドは、小さなクエリ文字列からの解析時間の短縮よりも大きい場合があります。また、オプティマイザが一時表を間違って推定すると、パーティション・プルーニングを使用しないなどの問題が発生する可能性があります。パフォーマンスが主な目標である場合は、大規模なリテラルをハードコーディングするなど、オプティマイザにできるだけ多くの情報を提供する必要があります。 –
Oracleオプティマイザは、IN-リストに変換しますOR鎖に結合する。これにより、クエリをさらに最適化できるOR-expansion transformationを実行できます。また、クエリを高速化できる推移的述語を生成することもできます。
2つのクエリ、構文、または変換ですべてが等しい場合、INまたはORの使用に違いはありません。 INはORチェーンに変換されます。
この質問はどのデータベースにも公開されており、異なるオプティマイザは異なる実装を持つことになります。その質問に対する回答は、MySQL固有のものです。また、オラクルについては、投票率の高い別の回答があります。 – givanse