SQL hat keine Reihenfolge der Ausführung. Es ist eine deklarative Sprache. Dem Optimierer steht es frei, jede beliebige Reihenfolge zu wählen, die er für geeignet hält, um die beste Ausführungszeit zu erzielen. Bei einer beliebigen SQL-Abfrage ist es im Grunde unmöglich, so zu tun, als ob man die Ausführungsreihenfolge kennt. Wenn man detaillierte Informationen über das betroffene Schema (genaue Definition der Tabellen und Indizes) und die geschätzten Kardinalitäten (Größe der Daten und Selektivität der Schlüssel) hinzufügt, kann man eine erraten bei der wahrscheinlichen Ausführungsanordnung.
Letztendlich ist die einzig richtige "Reihenfolge" diejenige, die im eigentlichen Ausführungsplan beschrieben ist. Siehe Anzeige von Ausführungsplänen mit Hilfe von SQL Server Profiler-Ereignisklassen y Grafische Anzeige von Ausführungsplänen (SQL Server Management Studio) .
Eine ganz andere Frage ist jedoch, wie sich Abfragen, Unterabfragen und Ausdrücke in die "Gültigkeit" projizieren lassen. Wenn Sie zum Beispiel einen Alias-Ausdruck in der SELECT-Projektionsliste haben, können Sie den Alias dann in der WHERE-Klausel verwenden? Etwa so:
SELECT a+b as c
FROM t
WHERE c=...;
Ist die Verwendung von c Alias in der Where-Klausel gültig? Die Antwort lautet NEIN. Abfragen bilden einen Syntaxbaum, und ein unterer Zweig des Baums kann nicht auf etwas verweisen, das weiter oben im Baum definiert ist. Dies hat nicht unbedingt etwas mit der Reihenfolge der "Ausführung" zu tun, sondern ist eher ein Problem der Syntaxanalyse. Es ist vergleichbar mit dem Schreiben dieses Codes in C#:
void Select (int a, int b)
{
if (c = ...) then {...}
int c = a+b;
}
Genau wie in C# lässt sich dieser Code nicht kompilieren, weil die Variable c verwendet wird, bevor es definiert ist, wird der obige SELECT nicht richtig kompiliert, weil der Alias c in der Baumstruktur weiter unten referenziert wird als tatsächlich definiert ist.
Im Gegensatz zu den bekannten Regeln für das Parsen von C/C#-Sprachen sind die SQL-Regeln für den Aufbau des Abfragebaums leider etwas esoterisch. Es gibt eine kurze Erwähnung davon in Verarbeitung einzelner SQL-Anweisungen aber eine ausführliche Diskussion darüber, wie sie erstellt werden und welche Reihenfolge gültig ist und welche nicht, kenne ich keine Quelle. Ich sage nicht, dass es keine guten Quellen gibt, ich bin sicher, dass einige der guten SQL-Bücher dieses Thema behandeln.
Beachten Sie, dass die Reihenfolge des Syntaxbaums nicht mit der visuellen Reihenfolge des SQL-Textes übereinstimmt. Zum Beispiel ist die ORDER BY-Klausel normalerweise die letzte im SQL-Text, aber als Syntaxbaum steht sie über allem anderen (sie sortiert die Ausgabe des SELECTs, liegt also sozusagen über den SELECT-Spalten) und ist als solches est gültig, um auf die c alias:
SELECT a+b as c
FROM t
ORDER BY c;
Aktualisiert
Tatsächlich gibt es dies: Logische Verarbeitungsreihenfolge der SELECT-Anweisung
Die folgenden Schritte zeigen die logische Verarbeitungsreihenfolge, oder Bindungsreihenfolge, für eine SELECT-Anweisung. Diese Reihenfolge bestimmt, wann die Objekte, die in einem Schritt definierten Objekte für die Klauseln in den nachfolgenden Schritten zur Verfügung gestellt werden. Für zum Beispiel, wenn der Abfrageprozessor auf die Tabellen oder Views binden (zugreifen) die in der FROM-Klausel definiert sind, werden diese Objekte und ihre Spalten für alle nachfolgenden für alle nachfolgenden Schritte zur Verfügung. Umgekehrt, da die SELECT-Klausel Schritt 8 ist, werden alle Spaltenalias oder abgeleitete Spalten, die in dieser Klausel definiert sind nicht von den vorangehenden Klauseln referenziert werden. Sie können jedoch durch nachfolgende Klauseln referenziert werden, wie wie die ORDER BY-Klausel. Beachten Sie, dass die tatsächliche physische Ausführung der Anweisung durch die Abfrage bestimmt wird Prozessor bestimmt wird, und die Reihenfolge kann von dieser Liste abweichen kann.
- VON
- ON
- JOIN
- WHERE
- GROUP BY
- MIT WÜRFEL oder MIT ROLLUP
- HABEN
- SELECT
- DISTINCT
- ORDER BY
- TOP
