現在、いくつかのテストを行っていますが、次のことに気付きました。
select field1 from table1
index fast full scan主キーがwhenになるためfield1、低コスト（私の場合は4690）になりますが、
select field2 from table1
117591のコストでtable access full(制約もインデックスもありませんがfield2、通常のインデックスでも結果は同じです) になります。
インデックス/制約が JOIN/WHERE 句に含まれている場合の利点は認識していますが、私の場合は何もフィルタリングされていません。とにかく、すべての行を取得しているため、PK を高速にする必要がある理由がわかりません。 ..
ユニークさゆえでしょうか。トムは、一意のインデックスは構造的には従来のインデックスと同じであると言います。これは、なぜ PK を選択すると他のどの列よりもコストがかからないのか疑問に思います。
あなたの啓発をありがとう:-)
rgds。
単一列の B ツリー インデックスは、NULL の行のデータを格納しません。そのため、インデックスを持っていても をfield2許可field2している場合NULL、Oracle はインデックスのスキャンを実行できず、誤ったデータが返される可能性があります。したがって、フル テーブル スキャンは、Oracle が のfield2すべての行の列のデータを取得するための唯一の有効な方法ですtable1。NOT NULLに制約を追加する場合field2、Oracle は少なくともインデックスのフル スキャンを実行することを検討できるはずです。
もちろん、オプティマイザーがインデックスの使用を選択するかどうか (およびインデックスの使用に最終的に割り当てるコスト) は、インデックスとテーブルの両方で収集した統計に依存します。統計が不正確な場合、オプティマイザーのコスト見積もりが不正確になり、生成される計画が非効率になる可能性があります。これが、オラクルによる計画のコストの見積もりを信用しすぎることに注意するよう人々に勧められる理由の 1 つです。コストに頼ることはできません。一般に、各ステップのカーディナリティの見積もりを見て、データの分布を考慮してそれらが理にかなっているかどうかを判断する方がはるかに役に立ちます。