Um die Performance bei der Abfrageverarbeitung zu verbessern, können Sie anhand der folgenden Tipps effizientere Abfragen aufbauen. Diese Tipps spiegeln Optimierungen wieder, die der Optimierer möglicherweise während der Abfrageverarbeitung wählen würde, um die Abfrage effizienter zu gestalten. Wenn Sie diese Effizienzen in die Abfrage integrieren, muss der Optimierer in der Regel weniger Arbeit verrichten.
Tipp | Vorher und nachher | Erklärung | ||||
---|---|---|---|---|---|---|
Eliminieren Sie nicht benötigte DISTINCT-Bedingungen. |
Vorher:
Nachher:
|
Das DISTINCT-Schlüsselwort in der ersten Anweisung ist unnötig, weil die Products-Tabelle den Primärschlüssel "p.ID" enthält, der Teil der Ergebnismenge ist. |
||||
Eliminieren Sie nicht benötigte DISTINCT-Bedingungen. |
Vorher:
Nachher:
|
Die erste Abfrage enthält die Primärschlüssel beider Tabellen, d.h., jede Zeile im Ergebnis muss unterschiedlich sein. |
||||
Entschachteln Sie Unterabfragen. |
Vorher:
Nachher:
|
Das Umschreiben von verschachtelten Abfragen in Joins führt häufig zu einer effizienteren Ausführung und effektiveren Optimierung. Allgemein werden korrelierte Unterabfragen mit nicht mehr als einer Tabelle in der FROM-Klausel, die in den Prädikaten ANY, ALL und EXISTS benutzt werden, immer entschachtelt. Eine nicht korrelierte Unterabfrage oder eine Unterabfrage mit mehr als einer Tabelle in der FROM-Klausel wird entschachtelt, wenn aufgrund der Abfragesemantik erkennbar ist, dass die Unterabfrage nicht mehr als eine Zeile liefert. In diesem Beispiel kann die Unterabfrage höchstens eine Zeile für jede Zeile im Außenblock in Übereinstimmung bringen. Weil hier immer nur eine Zeile gefunden wird, ist die Konvertierung in einen Inner-Join möglich. |
||||
Entschachteln Sie Unterabfragen. |
Vorher:
Nachher:
|
Die Abfrage unter "Vor" enthält ein konjunktives EXISTS-Prädikat in der Unterabfrage, das mit mehr als einer Zeile übereinstimmen kann. Sie kann mit DISTINCT in der SELECT-Liste in einen Inner-Join konvertiert werden. |
||||
Entschachteln Sie Unterabfragen. |
Vorher:
Nachher:
|
Eliminieren Sie Unterabfragen in Vergleichen, bei denen die Unterabfrage für jede Zeile im Außenblock mit höchstens einer Zeile übereinstimmt. |
||||
Ziehen Sie beim Abfragen einer indizierten Spalte in Erwägung, ein IN-Prädikat zu verwenden. |
Vorher:
Nachher:
|
In der umgeschriebenen Form kann das IN-Listen-Prädikat als sargable (als Suchargument nutzbar) behandelt und für den Abruf über den Index genutzt werden. Außerdem kann der Optimierer die IN-Liste sortieren, damit sie mit der Sortierfolge des Indexes übereinstimmt, was einen effizienteren Abruf zur Folge hat. Beachten Sie, dass die IN-Liste nur Konstanten enthalten darf oder Werte, die während einer Ausführung des Abfrageblocks konstant bleiben, z.B. äußere Referenzen. |
||||
Eliminieren Sie nicht benötigte Joins. |
Vorher:
Nachher:
|
Ziehen Sie die Eliminierung von Joins in Erwägung, wenn Folgendes zutrifft:
In diesem Fall ist der Join ein Primärschlüssel-Fremdschlüssel-Join, sodass die Primärschlüsseltabelle "Products" eliminiert werden kann. Die zweite Abfrage ist also der ersten semantisch gleichwertig, weil im Ergebnis keine Zeile aus der SalesOrderItems-Tabelle erscheint, die einen NULL-Fremdschlüssel zu "Products" enthält. |
||||
Eliminieren Sie nicht benötigte Joins. |
Vorher:
Nachher:
|
In der ersten Abfrage kann das Schlüsselwort OUTER JOIN eliminiert werden, weil der nullwertliefernde Tabellenausdruck für jede Zeile der beibehaltenen Seite höchstens eine Zeile erzeugen kann und keine der Spalten von "Products" oberhalb der LEFT OUTER JOIN-Anweisung verwendet wird. |
||||
Eliminieren Sie unnötige Konvertierungen der Groß- und Kleinschreibung. |
Vorher:
Nachher:
|
In einer Datenbank, die keine Groß- und Kleinschreibung berücksichtigt, kann die erste Abfrage so umgeschrieben werden, dass der Optimierer die Möglichkeit hat, einen Index für "Customers.Surname" zu verwenden. Standardmäßig führt der Datenbankserver Zeichenfolgenvergleiche ohne Berücksichtigung von Groß- und Kleinschreibung durch, es sei denn, es werden explizite Anweisungen zur Textkonvertierung gegeben (Verwendung von UPPER, UCASE, LOWER oder LCASE). Durch Eliminieren unnötiger Konvertierungen der Groß- und Kleinschreibung können die Prädikate in sargable-Prädikate umgewandelt und dann für Indexabrufe der entsprechenden Tabelle verwendet werden. |
||||
Ziehen Sie das Inlining von Funktionen in Erwägung. |
Vorher:
Nachher:
|
Ein Inlining einer benutzerdefinierten Funktion ist möglich, wenn diese eine der folgenden Voraussetzungen erfüllt:
Dieser Tipp ist nicht anwendbar auf temporäre Funktionen, rekursive Funktionen und Funktionen mit NOT DETERMINISTIC-Klausel. Außerdem ist dieser Tipp nicht anwendbar, wenn die betreffende Funktion mit einer Unterabfrage als Argument oder aus einer temporären Prozedur heraus aufgerufen wird. |
||||
Ziehen Sie das Inlining einfacher gespeicherter Prozeduren in Erwägung. |
Vorher:
Nachher:
|
Das Inlining einer gespeicherten Prozedur ist möglich, wenn diese beim Aufrufen in der FROM-Klausel einer Abfrage nur als eine einzige SELECT-Anweisung festgelegt wird. Wenn eine Prozedur inline ist, wird sie als abgeleitete Tabelle umgeschrieben. Dieser Tipp gilt nicht für Prozeduren, in denen Standardargumente verwendet werden oder deren Hauptteil etwas anderes enthält als eine einzige SELECT-Anweisung. |
![]() |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2012, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.1 |