Das Konzept von Rowid:
rowid ist eine Pseudospalte. Da es sich um eine Pseudospalte handelt, wird diese Spalte nicht vom Benutzer definiert, sondern vom System selbst hinzugefügt. Für jede Tabelle gibt es eine Rowid-Pseudospalte, der Wert der ROWID-Spalte wird jedoch nicht physisch in der Tabelle gespeichert. Sie können sie jedoch wie jede andere Spalte verwenden, jedoch weder die Spalte löschen oder ändern noch den Wert der Spalte ändern oder einfügen. Sobald eine Datenzeile in die Datenbank eingefügt wird, ist die Zeilen-ID während des Lebenszyklus der Zeile eindeutig. Das heißt, selbst wenn die Zeile einer Zeilenmigration unterzogen wird, ändert sich die Zeilen-ID nicht.
Warum ROWID verwenden?
rowid bietet die schnellste Zugriffsmethode auf eine bestimmte Zeile in einer Tabelle. Der entsprechende Datenblock kann direkt über ROWID gefunden und dann in den Speicher eingelesen werden. Wenn wir einen Index erstellen, speichert der Index nicht nur den Wert der Indexspalte, sondern auch die ROWID der Zeile, die dem Indexwert entspricht. Auf diese Weise finden wir schnell die ROWID der entsprechenden Zeile über den Index. Wir können die Daten schnell über die ROWID abfragen. Aus diesem Grund ist es schneller, wenn wir Indexabfragen verwenden.
In früheren Versionen von ORACLE8 bestand ROWID aus FILE, BLOCK und ROW NUMBER. Mit der Erweiterung des Objektkonzepts in Oracle8 hat sich ROWID geändert und besteht aus OBJECT, FILE, BLOCK und ROW NUMBER. Sie können DBMS_ROWID verwenden, um die Zeilen-ID in die oben genannten Teile zu zerlegen, oder Sie können die oben genannten Teile zu einer gültigen Zeilen-ID kombinieren.
Rekursives SQL-Konzept Um eine vom Benutzer ausgegebene SQL-Anweisung auszuführen, muss Oracle manchmal einige zusätzliche Anweisungen ausführen. Wir nennen diese zusätzlichen Anweisungen „rekursive Aufrufe“ oder „rekursive SQL-Anweisungen“. Wenn beispielsweise eine DDL-Anweisung ausgegeben wird, gibt ORACLE implizit immer einige rekursive SQL-Anweisungen aus, um die Datenwörterbuchinformationen zu ändern, damit der Benutzer die DDL-Anweisung erfolgreich ausführen kann. Rekursive Aufrufe treten häufig auf, wenn sich die erforderlichen Datenwörterbuchinformationen nicht im gemeinsam genutzten Speicher befinden. Diese rekursiven Aufrufe lesen die Datenwörterbuchinformationen von der Festplatte in den Speicher. Benutzer kümmern sich nicht um die Ausführung dieser rekursiven SQL-Anweisungen. ORACLE führt diese Anweisungen bei Bedarf automatisch intern aus. Natürlich können sowohl DML-Anweisungen als auch SELECT zu rekursivem SQL führen. Einfach ausgedrückt können wir uns Trigger als rekursives SQL vorstellen.
Zeilenquelle
Bei Verwendung in Abfragen kann es sich bei der Menge der von der vorherigen Operation zurückgegebenen qualifizierenden Zeilen um eine Menge aller Zeilendaten in der Tabelle handeln; es kann sich auch um eine Menge von Teilzeilendaten in der Tabelle handeln; Zeilenquellen Eine Sammlung von Zeilendaten, die nach einem Verbindungsvorgang (z. B. einer Join-Verbindung) abgerufen werden.
Prädikat
WHERE-Einschränkungen in einer Abfrage
Fahrtisch
Diese Tabelle wird auch äußere Tabelle (OUTER TABLE) genannt. Dieses Konzept wird in verschachtelten und HASH-Joins verwendet. Wenn die Zeilenquelle mehr Zeilendaten zurückgibt, wirkt sich dies negativ auf alle nachfolgenden Vorgänge aus. Beachten Sie, dass dies zwar als „treibende Tabelle“ übersetzt wird, genauer aber als „treibende Zeilenquelle“ übersetzt wird. Im Allgemeinen wird nach dem Anwenden von Abfragebeschränkungen die Tabelle mit weniger Zeilenquellen als treibende Tabelle zurückgegeben. Wenn daher eine große Tabelle Einschränkungen (z. B. Gleichheitseinschränkungen) in der WHERE-Bedingung aufweist, wird die große Tabelle auch als treibende Tabelle verwendet Es ist angemessen, dass nur kleinere Tabellen als treibende Tabellen verwendet werden können. Die richtige Aussage sollte sein, dass nach Anwendung der Abfrageeinschränkungen die Tabelle als treibende Tabelle verwendet wird. Im Ausführungsplan sollte es sich um die Quelle der oberen Zeile handeln. Spezifische Anweisungen werden später gegeben. In unserer nachfolgenden Beschreibung wird diese Tabelle allgemein als Zeilenquelle 1 der Join-Operation bezeichnet.
Geprüfte Tabelle (geprüfte Tabelle)
Diese Tabelle wird auch innere Tabelle (INNER TABLE) genannt. Nachdem wir eine bestimmte Datenzeile aus der Treibertabelle erhalten haben, suchen wir in der Tabelle nach Zeilen, die die Join-Bedingungen erfüllen. Die Tabelle sollte also eine große Tabelle sein (eigentlich sollte es eine Tabelle sein, die eine größere Zeilenquelle zurückgibt) und es sollten Indizes für die entsprechenden Spalten vorhanden sein. In unserer nachfolgenden Beschreibung wird diese Tabelle allgemein als Zeilenquelle 2 der Join-Operation bezeichnet.
kombinierter Index (verketteter Index)
Ein Index, der aus mehreren Spalten besteht, wie zum Beispiel den Index idx_emp für emp(col1, col2, col3, ...) erstellen, dann nennen wir den idx_emp-Index einen zusammengesetzten Index. Im kombinierten Index gibt es ein wichtiges Konzept: die führende Spalte. Im obigen Beispiel ist die Spalte col1 die führende Spalte. Wenn wir eine Abfrage durchführen, können wir „where col1 = ?“ und „where col1 = ?“ verwenden. Bei solchen Einschränkungen wird der Index verwendet, bei der Abfrage „where col2 = ?“. Daher wird der kombinierte Index nur dann für die Einschränkung verwendet, wenn die führende Spalte in der Einschränkung enthalten ist.
Selektivität:
Der Vergleich der Anzahl eindeutiger Schlüssel in einer Spalte mit der Anzahl der Zeilen in der Tabelle bestimmt die Selektivität der Spalte. Wenn das Verhältnis „Anzahl der eindeutigen Schlüssel/Anzahl der Zeilen in der Tabelle“ der Spalte näher bei 1 liegt, ist die Selektivität der Spalte höher, die Spalte eignet sich besser zum Erstellen eines Index und die Selektivität des Index ist auch höher. Bei der Abfrage von stark auswählbaren Spalten werden weniger Daten zurückgegeben, sodass Indexabfragen besser geeignet sind.
Mit diesem Hintergrundwissen beginnen wir mit der Einführung des Ausführungsplans. Um eine Anweisung auszuführen, muss Oracle möglicherweise viele Schritte implementieren. Jeder dieser Schritte kann darin bestehen, die Datenzeilen physisch aus der Datenbank abzurufen oder sie auf irgendeine Weise für die Verwendung durch den Benutzer vorzubereiten, der die Anweisung ausgibt. Die Kombination dieser Schritte, die Oracle zum Ausführen einer Anweisung verwendet, wird als Ausführungsplan bezeichnet. Der Ausführungsplan ist der komplexeste und kritischste Teil der SQL-Optimierung. Nur wenn wir wissen, wie ORACLE die SQL-Anweisung intern ausführt, können wir wissen, ob der vom Optimierer ausgewählte Ausführungsplan optimal ist. Ausführungspläne sind für DBAs genauso wichtig wie Finanzberichte für das Finanzpersonal. Die Hauptprobleme, mit denen wir konfrontiert sind, sind also: Wie erhält man den Ausführungsplan? Wie analysiert man den Ausführungsplan, um die Hauptprobleme herauszufinden, die sich auf die Leistung auswirken? Im Folgenden wird mit der Analyse des Baumausführungsplans begonnen, dann wird vorgestellt, wie man den Ausführungsplan erhält, und dann wird vorgestellt, wie man den Ausführungsplan analysiert.
Beispiel:
Dieses Beispiel zeigt den Ausführungsplan für die folgende SQL-Anweisung.
SELECT ename, job, sal, dname
VON emp, Abt
WHERE emp.deptno = derpt.deptno
UND NICHT EXISTIERT
(WÄHLEN *
VON salgrade
WO emp.sal ZWISCHEN losal UND hisal );
Diese Anweisung fragt den Namen, die Stelle, das Gehalt und den Abteilungsnamen aller Mitarbeiter ab, deren Gehalt nicht in eine der empfohlenen Gehaltsspannen fällt.
Dieser Artikel stammt aus dem CSDN-Blog. Bitte geben Sie beim Nachdruck die Quelle an: http://blog.csdn.net/lcyhjx/archive/2009/12/20/5044672.aspx