Rowid の概念:
rowid は擬似列であるため、この列はユーザーによって定義されるのではなく、システム自体によって追加されます。各テーブルには ROWID 疑似列がありますが、ROWID 列の値はテーブルに物理的に格納されません。ただし、他の列と同様に使用できますが、列を削除または変更したり、列の値を変更または挿入したりすることはできません。データ行がデータベースに挿入されると、ROWID は行のライフサイクル全体にわたって一意になります。つまり、行が行移行されたとしても ROWID は変わりません。
ROWIDを使用する理由
rowid は、テーブル内の特定の行への最速のアクセス方法を提供し、ROWID を通じて対応するデータ ブロックを直接見つけてメモリに読み込むことができます。インデックスを作成すると、インデックスにはインデックス列の値が保存されるだけでなく、インデックスを通じて対応する行の ROWID がすぐに見つかった後、インデックス値に対応する行の ROWID も保存されます。 ROWID を使用してデータをすばやくクエリできます。これが、インデックス クエリを使用すると高速になる理由です。
ORACLE8 の以前のバージョンでは、ROWID は FILE、BLOCK、ROW NUMBER で構成されていました。 Oracle8 ではオブジェクトの概念が拡張され、ROWID は OBJECT、FILE、BLOCK、ROW NUMBER で構成されています。 DBMS_ROWID を使用して ROWID を上記の部分に分解することも、上記の部分を結合して有効な ROWID にすることもできます。
再帰 SQL の概念 ユーザーが発行した SQL ステートメントを実行するために、Oracle は追加のステートメントを「再帰呼び出し」または「再帰 SQL ステートメント」と呼びます。たとえば、DDL ステートメントが発行されると、ORACLE は常に暗黙的にいくつかの再帰 SQL ステートメントを発行してデータ ディクショナリ情報を変更し、ユーザーが DDL ステートメントを正常に実行できるようにします。再帰呼び出しは、必要なデータ ディクショナリ情報が共有メモリにない場合によく発生します。これらの再帰呼び出しは、データ ディクショナリ情報をハード ディスクからメモリに読み取ります。ユーザーは、これらの再帰 SQL ステートメントの実行を気にする必要はありません。ORACLE は、必要に応じてこれらのステートメントを内部で自動的に実行します。もちろん、DML ステートメントと SELECT の両方で再帰 SQL が発生する可能性があります。簡単に言えば、トリガーは再帰 SQL と考えることができます。
行ソース
クエリで使用される場合、前の操作によって返される条件を満たす行のセットは、テーブル内のすべての行データのセットである場合もあれば、テーブル内の部分的な行データのセットである場合も、上記 2 つのセットである場合もあります。行ソース。接続操作 (結合接続など) の後に取得された行データのコレクション。
述語
クエリ内の WHERE 制約
ドライビングテーブル
この表を外表（OUTER TABLE）ともいいます。この概念は、ネストされた結合と HASH 結合で使用されます。行ソースがさらに多くの行データを返すと、後続のすべての操作に悪影響が生じます。これは駆動テーブルとして翻訳されていますが、実際には駆動行ソースとしてより正確に翻訳されることに注意してください。一般に、クエリ制限を適用すると、行ソースの少ないテーブルが駆動テーブルとして返されます。そのため、大きなテーブルに WHERE 条件に制限 (等価制限など) がある場合、その大きなテーブルも駆動テーブルとして使用されます。したがって、クエリ制約を適用した後、より少ない行ソースを返すテーブルが駆動テーブルとして使用されるというのが正しい表現です。実行計画では、上段のソースになります。具体的な手順は後述します。以降の説明では、このテーブルを一般に結合操作の行ソース 1 と呼びます。
プローブされたテーブル (プローブされたテーブル)
この表を内部表(INNER TABLE)ともいいます。ドライバー テーブルから特定のデータ行を取得した後、テーブル内で結合条件を満たす行を探します。したがって、テーブルは大きなテーブルである必要があり (実際には、より大きな行ソースを返すテーブルである必要があります)、対応する列にインデックスが必要です。以降の説明では、このテーブルを一般に結合操作の行ソース 2 と呼びます。
結合インデックス (連結インデックス)
emp(col1、col2、col3、...) にインデックス idx_emp を作成するなど、複数の列で構成されるインデックスの場合、idx_emp インデックスを複合インデックスと呼びます。結合インデックスには重要な概念があります。それは先頭列です。上の例では、col1 列が先頭列です。クエリを作成するときは、「where col1 = ?」または「where col1 = ? and col2 = ?」を使用できますが、「where col2 = ?」クエリはインデックスを使用しません。したがって、先頭列が制限に含まれる場合にのみ、結合インデックスが制限に使用されます。
選択性:
列の一意のキーの数とテーブルの行の数を比較することで、列の選択性が決まります。列の「一意のキーの数/テーブルの行数」の比率が 1 に近いほど、列の選択性が高く、その列はインデックスの作成に適しており、インデックスの選択性が高くなります。も高いです。選択性の高い列に対してクエリを実行すると、返されるデータが少なくなるため、インデックス クエリの方が適しています。
このような背景知識を整えた上で、実行計画の導入を開始します。ステートメントを実行するために、Oracle は多くの手順を実装する必要がある場合があります。これらの各ステップでは、データベースからデータ行を物理的に取得したり、ステートメントを発行するユーザーが使用できるように何らかの方法でデータ行を準備したりすることができます。 Oracle がステートメントを実行するために使用するこれらのステップの組み合わせは、実行計画と呼ばれます。実行計画は、SQL 最適化の最も複雑かつ重要な部分です。ORACLE が内部で SQL ステートメントを実行する方法を知ることによってのみ、オプティマイザーによって選択された実行計画が最適であるかどうかを知ることができます。財務担当者にとって財務諸表が重要であるのと同じように、DBA にとって実行計画は重要です。したがって、私たちが直面する主な問題は、実行計画を取得する方法と、実行計画を分析してパフォーマンスに影響を与える主な問題を見つける方法です。以下では、ツリー実行計画の分析から開始し、次に実行計画の取得方法を紹介し、次に実行計画の分析方法を紹介します。
例：
この例は、次の SQL ステートメントの実行計画を示しています。
SELECT ename、job、sal、dname
従業員、部門から
WHERE emp.deptno = derpt.deptno
そして存在しない
(選択 *
サルグラードから
losal と hisal の間の emp.sal );
このステートメントは、給与が推奨給与範囲のいずれにも該当しないすべての従業員の名前、役職、給与、部門名を照会します。
この記事は CSDN ブログからのものです。転載する場合は出典を明記してください: http://blog.csdn.net/lcyhjx/archive/2009/12/20/5044672.aspx