20

クエリのパフォーマンスを最適化しようとしていますが、オプティマイザ ヒントを使用する必要がありました。しかし、オプティマイザーが一度に複数のヒントを使用するかどうかはわかりません。

例えば

SELECT /*+ INDEX(i dcf_vol_prospect_ids_idx)*/
       /*+ LEADING(i vol) */ 
       /*+ ALL_ROWS */ 
       i.id_number,
       ...
  FROM i_table i
  JOIN vol_table vol on vol.id_number = i.id_number
  JOIN to_a_bunch_of_other_tables...
 WHERE i.solicitor_id = '123'
   AND vol.solicitable_ind = 1;

説明計画は同じコストを示していますが、それは単なる見積もりであることはわかっています。

すべてのテーブルとインデックスの統計が計算されていると想定してください。参考までに、インデックス dcf_vol_prospect_ids_idx は i.solicitor_id 列にあります。

ありがとう、

シチュー

4

3 に答える 3

24

すばらしい Oracle ドキュメント ( http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/hintsref.htm )のこの例に示されているように、単一のコメント ブロックですべてのヒントを指定してみてください。

16.2.1 ヒントの完全なセットの指定

ヒントを使用する場合、最適な実行計画を確保するために、ヒントの完全なセットを指定する必要がある場合があります。たとえば、多くのテーブル結合で構成される非常に複雑なクエリがあり、特定のテーブルに INDEX ヒントのみを指定した場合、オプティマイザは使用する残りのアクセス パスと対応するアクセス パスを決定する必要があります。結合方法。したがって、INDEX ヒントを与えたとしても、オプティマイザーは必ずしもそのヒントを使用するとは限りません。これは、オプティマイザーが選択した結合方法とアクセス パスが原因で、要求されたインデックスを使用できないとオプティマイザーが判断した可能性があるためです。

例16-1では、 LEADING ヒントで使用する正確な結合順序を指定しています。異なるテーブルで使用される結合方法も指定されています。

例16-1 ヒントの完全なセットの指定

SELECT /*+ LEADING(e2 e1) USE_NL(e1) INDEX(e1 emp_emp_id_pk)
           USE_MERGE(j) FULL(j) */
    e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal  
FROM employees e1, employees e2, job_history j
WHERE e1.employee_id = e2.manager_id
  AND e1.employee_id = j.employee_id
  AND e1.hire_date = j.start_date
GROUP BY e1.first_name, e1.last_name, j.job_id   ORDER BY total_sal;
于 2009-01-07T20:49:58.043 に答える
2

実際、コストベースのOracleFundamentalsの作成者であるJonathanLewisの推奨事項は、CBOが正しい計画を見つけられなかった場合、CBOの仕事を引き継ぎ、ヒントを「レイヤーイン」する必要があるというものです。クエリのテーブルごとに2つのヒント。

その理由は、あるヒントが、CBOが支援するよりもさらに悪い、場合によってはさらに悪い計画につながる可能性があるためです。CBOが間違っている場合は、正しい方向に微調整するだけでなく、計画全体を提示する必要があります。

于 2009-01-07T22:47:24.673 に答える