SQL最適化の基本原理

光学ドライブ

SQL文の最適な実行方法を決定し、計画をエクスポートし、SQL文をグループ化して実行します.
エンジン

クエリー変換器(Query Transfermer):オプティカル(光学式)ドライブを変換してSQL文を効率よく実行する

コスト見積り器:SQL運転コスト計算

グローバル置換計画ビルダー:複数のグローバル置換計画を生成
-①演算適用順②演算方法③連結順序の変更

種類

ルールベースのオプティカル(光学式)ドライブ:優先度ルールに従って実行計画を作成し、インデックスがあればインデックスを使用する必要がある

コストベースの光学ドライブ:処理コストが最も低い実行計画を選択する.統計が不十分な場合、パフォーマンスは低下します.
SQL処理フローチャート:SQL文処理フローを直感的に示すグラフ
実施計画:①個体②連結方法及び手順③出口モード等の情報出力
DESC PLAN TABLE:実行計画確認
解毒手順:←探索中に2行以上の同一レベルに遭遇した↓解毒を行う

索引

インデックスキーでソートすると、クエリーの速度が速く、検索効率が高くなります.
DML効率低下
ツリーベースのインデックス:DBMSで使用される最も一般的なインデックス.Root, Branch, Leaf

Branch Block:次のアドレスを持つPointer

Leaf Block:インデックスキーとRowidからなり、ダブルリンクリスト構造(双方向)

クラスタインデックス

インデックスのページにデータが含まれている

リフページのすべての小文字をインデックス・キー・バー順に物理ソート

作成

create index 인덱스명 on 테이블명(칼럼명);

※ Rowid
Oracleが提供する一意のデータ区分、自動生成、データロケーション通知、
オブジェクト番号、相対ファイル番号、ブロック番号、データ番号

インデックススキャン

効率の向上:ランダムな出口を最小限に抑える
※ランダムEXSES:インデックススキャン後にソートを追加し、性能負荷を引き起こす
に道を教える
≪索引ユニーク・スキャン｜Index Unique Scan｜oem_src≫:索引キーが重複しない場合、データは1つだけ抽出されます.最も速く、ピア条件が検索されます.
≪索引範囲スキャン｜Index Range Scan｜oem_src≫:特定の範囲のスキャン索引逆順序範囲スキャン:二重リンク・リストの使用
フルインデックススキャン:すべてのLeaf Blockを読み込み、スキャン
インデックス高速フルスキャン
インデックススキャン
≪索引組織表｜Index Organization Table｜oem_src≫:索引キーを含む列の表.元の表はXを参照し、クラスタ表と同様

けつごうげんり

オーダー

前置き表:First Table、Outer Table、Drive Table、Build Input

後続表
-前のテーブルから入力値を受信して処理します.後のテーブルの結合条件はパフォーマンスに大きな影響を与えます.
- Second Table, Inner Table, Driven Table, Probe Table

モード
Nested Loop Join

前の表のデータが順次接続されている(重複重複する文のようなもの)

前置表処理範囲決定性エネルギー

ランダムアクセスがメインで大容量データの処理には不都合

ユニークインデックスを使用した少量のデータガラス

接続結果を直接出力、OLT P環境に適合

手順:条件を満たす行を検索→後続のプリセットキーの存在を確認→後続インデックスにおけるプリセットキーの存在を確認→Rowidを使用して後続テーブルにアクセス

Sort Merge Join

2つのテーブルをそれぞれスキャンしてサイン

テクスチャの有無は性能にあまり影響しない

大容量データの処理時にディスクがソートされるため、性能に不利

Hash Join

連結コラム基準により同一ハッシュ値を有するデータの実績値を比較し、連結・差が大きい場合はガラスを用いる

ハッシュメモリにハッシュテーブルを作成するので、前置きテーブルが小さい場合はガラス、キット負荷の重いブロックガラスを使用する

NL JoinのランダムアクセスとSort Merge Joinのソートワークロードを解決し、ピアツーピアジョインで使用

OLAP環境に適合

Can Do It
brb