DB]変換クエリー-ビューマージ

ビューマージは

select * 
from (select * from emp where job = 'SALESMAN') a
,    (select * from dept where loc = 'CHICAGO') b
where a.deptno = b.deptno;

上記のクエリはよく見られます.
開発者の立場に立った方が分かりやすいからです.
サブクエリも結合文よりも直感的です.
しかし、擎天柱は最適化を実行する立場ではさらに不便だ.
したがって、オプティカル(光学式)ドライブは、クエリー・ブロックをできるだけ解放する習慣があります.
したがって、次のビューでクエリーをマージして変換します.

select *
from emp a, dept b
where a.deptno = b.deptno
and a.job = 'SALESMAN'
and b.loc = 'CHICAGO';

結果セットは同じですが、より多くのアクセスパスを考慮し、最大の効率を考慮しました.
この機能を制御するヒントにはmergeとno mergeが含まれます.
単純ビューと複合ビュー
単純ビューは、条件セクション、結合ドアの程度にのみ適用される単純な構造ビューです.
No mergeプロンプトを使用しない限り、ビューのマージは常に発生します.
複合ビューはgroupbyセクションとselect-listの異なる演算子を含むクエリーで、complex view mergingパラメータをtrueに設定した場合にのみMergingが発生します.
9 iから、デフォルト値はtrueなので、同じ結果をもたらすと思うと、常にマージが発生します.これはmergeがいつもより良い実行計画を見つける可能性が高いと信じているからです.
ビューのクエリーをマージできません
観覧ができないという条件があります.

集合演算子(union,union all,intercept,minus)

connect byセクション

Rownumダミー

select-listで集約関数を使用する(groupbyがない場合は全体を集約する)

解析関数

上記の条件では、絶対に美容美髪は発生しません.
例

サンプルコード.インラインビューでは、empテーブルを参照してdeptnoで平均給与を返します.
しかし,最終的にdeptテーブルにチェックインするとd.loc=は「CHICAGO」の条件を満たすレコードのみを返すため,empテーブルで読み取ったデータには破棄されたレコードが多い.

(오라클 성능 고도화 2권 493p에서 10g 이상에서는 비용을 따진뒤
ビューマージ(View Merge)のコストがより低いと判断すると、ビューマージ(View Merge)が自動的に発生します.
しかし,実践環境では効率が低下するという問題があるにもかかわらず,no mergeヒントがなくても
自動ビューマージは発生しませんでした.
この部分はまた探します.
いずれにしても、これは上記のコードの実行結果です.

まず内部ビューを実行します.(ID 4,5,6,7)
このうち4番目のVIEW実行計画は、EMPテーブルにアクセスした後のView操作に相当する.
DEPTテーブルにアクセスした後、ハッシュ結合を使用して結果セットをエクスポートします.
明らかに、empテーブルは破棄するテーブルとともに読み込まれるため、非効率性があるに違いない.

合併状況

上の図に示すように、ビューがマージされると、d.loc="CHICAGO"のレコードのみがDEPTテーブルで検索されてチェックインされ、GROUPByが得られる.
いつですか.
9 iでは、結果セットが同じであれば無条件にビューマージが生成されるが、10 gではコストが考慮され、ビューマージに変更される.
ビューのマージにはパフォーマンスの比較と使用が必要です.
上の図に示すように、d.loc=「CHICAGO」で選択したdeptnoがempテーブルにたくさんあるとしたら?チェックイン後のアクセスではなくTable Full Scandを使用して、より効率的にチェックインします.
したがって、ユーザーはコストをよくチェックし、mergeまたはno mergeプロンプトを使用する必要があります.
もしだめなら.
ビュー加工のコストが高いか、結果セットが正しくないと判断した場合は、ビュー加工を放棄します.このとき,無条件に2回目の条件プッシュを試みる.
失敗した場合でも、ビュー・クエリー・ブロックを個別に最適化し、生成されたサブ計画を完全な実行計画の生成に使用できます.