結合のないOracleIN句のパフォーマンスへの影響は何ですか？

テーブルの統計が正確である場合、WHEREにハードコードされた要素が1000個しかない場合に、オプティマイザが主キーインデックスを使用せずにテーブルスキャンを実行することを選択する可能性はほとんどありません。句。最善のアプローチは、オブジェクトの正確な統計を収集（または設定）することです。これにより、誤った統計を回避するために多くの体操を試みるのではなく、自動的に良いことが起こるはずです。

統計が不正確で、オプティマイザーが主キーインデックスを使用するよりもテーブルスキャンの方が効率的であると信じるほど不正確であると想定する場合は、DYNAMIC_SAMPLINGを追加できる可能性があります。ステートメントまたはCARDINALITYを最適化する前に、オプティマイザーがより正確な統計を収集するように強制するヒントオプティマイザのデフォルトのカーディナリティ推定を上書きするためのヒント。どちらも、使用可能なインデックスについて何も知る必要はなく、テーブルのエイリアス（またはエイリアスがない場合は名前）を知っている必要があります。 DYNAMIC_SAMPLING より安全で堅牢なアプローチですが、解析ステップに時間がかかります。

INに可変数のハードコードされたパラメータを使用してSQLステートメントを作成する場合条項では、共有プールを共有不可能なSQLで溢れさせ、データベースに各バリアントを個別に解析するために多くの時間を費やすことにより、パフォーマンスの問題が発生する可能性があります。一度解析できる単一の共有可能なSQLステートメントを作成した方がはるかに効率的です。 INの場所によって異なります句の値はから来ています、それは次のように見えるかもしれません

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM global_temporary_table);

または

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM TABLE( nested_table ));

または

SELECT *
  FROM table_name
 WHERE primary_key IN (SELECT primary_key
                         FROM some_other_source);

単一の共有可能なSQLステートメントにたどり着いた場合、ステートメントを絶えず再解析するコストを回避することに加えて、SQLステートメントの変更を伴わない特定の計画を強制するためのいくつかのオプションがあります。 Oracleのバージョンが異なれば、プランの安定性に関するオプションも異なります。保存されたアウトライン、SQL計画管理、およびSQLプロファイル> リリースに応じて、他のテクノロジーの中でも特に。これらを使用して、特定のSQLステートメントの特定の計画を強制できます。ただし、再解析が必要な新しいSQLステートメントを生成し続けると、これらのテクノロジを使用することが非常に困難になります。