のOracle実行計画私は、クエリを持って

Question

を変更：

   SELECT COUNT(1) 
      FROM registration r, 
        proxy p 
      WHERE r.participant_code = p.participant_code 
       AND r.proxy_type = p.proxy_type 
       AND r.proxy_value = p.proxy_value 
       AND r.proxy_sequence= p.proxy_sequence 

で使用されるすべての4つのフィールドがテーブルの結合条件を「プロキシ」 'プロキシのプライマリキーです。クエリの実行計画はプライマリキーを使用してスキャンを行っていますが、一瞬して突然フルテーブルスキャンでインデックススキャンを変更しました。

そのクエリが変更された後に少し（ 'r.proxy_value = p.proxy_value' およびスワップ 'r.proxy_type = p.proxy_type' を接合する）：

   SELECT COUNT(1) 
      FROM registration r, 
        proxy p 
      WHERE r.participant_code = p.participant_code 
       AND r.proxy_value = p.proxy_value     
       AND r.proxy_type = p.proxy_type 
       AND r.proxy_sequence= p.proxy_sequence 

実際両方のクエリは同等です。ただし、この変更後、2回目のクエリの実行計画では、フルスキャンではなくインデックススキャンが使用されます。

今、私は非常に具体的な質問があります。

Oracleは2番目のクエリを再コンパイルし、それが実行計画の変更を照会するためにつながりますか？

Answer 1

オラクルでは、データウェアハウスのシナリオでは予測性は向上しましたが、従来のルールベースオプティマイザと比較して、デフォルトでコストベースオプティマイザ（CBO）が使用されるようになりました。

一般に、CBOは「計画の安定性」の問題を導入しましたが、RBOの計画は常に同じままでした。

CBOを使用することは、統計および/または動的サンプリングデータの変更に基づいて実行プランを独自に変更することができ、変更されることを意味します。実際には、プランの切り替え履歴を監視できるツールがあります（lab128など）。

クエリを見たときに気づいたもう1つの点：フィルターがないため、実際の主キーが何であるかに応じて、インデックススキャンの用途がほとんどないことがあります。