WHERE und JOIN Reihenfolge der Operation

Question

Meine Frage ist ähnlich zu diesem SQL order of operations aber mit einem kleinen Twist, also ich denke, es ist fair zu fragen.

Ich benutze Teradata. Und ich habe 2 Tabellen: table1, table2.

table1 hat nur eine id Spalte.
table2 hat die folgenden Spalten: id, val

Ich könnte falsch sein, aber ich denke, diese beiden Aussagen die gleichen Ergebnisse liefern.

Statement 1.

SELECT table1.id, table2.val 
FROM table1 
INNER JOIN table2 
ON table1.id = table2.id 
WHERE table2.val<100 

Statement 2.

SELECT table1.id, table3.val 
FROM table1 
INNER JOIN (
    SELECT * 
    FROM table2 
    WHERE val<100 
) table3 
ON table1.id=table3.id 

Meine Fragen ist, wird der Abfrageoptimierer
intelligent genug sein - führen Sie die WHERE-Klausel erst dann später JOIN in Anweisung 1
- wissen, dass Tabelle 3 nicht wirklich in Anweisung 2 benötigt wird

Ich bin ziemlich neu in SQL, also bitte erziehe mich, wenn ich etwas falsch verstehe.

Answer 1

dies auf viele, viele Dinge (Tabellengröße, Index, Schlüsselverteilung, usw.) abhängen, sollten Sie nur die Planausführung überprüfen:

Sie nicht sagen, Datenbank, aber hier sind einige Möglichkeiten:
MySql EXPLAIN
SQL Server SET SHOWPLAN_ALL (Transact-SQL)
Oracle EXPLAIN PLAN

what is explain in teradata?
Teradata Capture and compare plans faster with Visual Explain and XML plan logging

Answer 2

Es sei denn, ich vermisse etwas, warum brauchen Sie sogar Table1 ??

abfragen Nur Table2

Select id, val 
From table2 
WHERE val<100 

oder verwenden Sie die Zeilen in Tabelle 1 als ein Filter? h., Ist Tabelle 1 nur eine Teilmenge der Ids in Tabelle 2?

Wenn ja, dann wird dies auch funktionieren ...

Select id, val 
From table2 
Where val<100 
    And id In (Select id 
       From table1) 

Aber um Ihre Frage zu beantworten, ja der Abfrageoptimierer intelligent genug sein soll, die beste Reihenfolge, in der, um herauszufinden, notwendig, um die Schritte auszuführen um Ihre logischen Anweisungen in ein physikalisches Ergebnis zu übersetzen. Es verwendet die von der Datenbank verwalteten Statistiken für jede Tabelle, um zu bestimmen, was zu tun ist (welche Art von Verknüpfungslogik zum Beispiel zu verwenden ist), sowie die Reihenfolge, in der die Operationen ausgeführt werden sollen, um Festplatten-IOs und Verarbeitungskosten zu minimieren.

Answer 3

Q1. führe zuerst die WHERE-Klausel und dann später in Anweisung 1

Die Sache ist, wenn Sie die Reihenfolge der inneren Join, dh Tabelle2 INNER JOIN table1, dann denke ich, WHERE-Klausel kann vor JOIN-Vorgang verarbeitet werden, während der Vorbereitungsphase .Ich denke jedoch, selbst wenn Sie die ursprüngliche Abfrage nicht ändern, sollte der Optimierer in der Lage sein, ihre Reihenfolge zu ändern, wenn er denkt, dass die Join-Operation zu teuer ist, wenn die ganze Zeile abgerufen wird. Nur meine Vermutung.

Q2. wissen, dass Tabelle 3 in Statement 2 nicht benötigt wird

Teradata wird Ihre zweite Abfrage so interpretieren, dass die abgeleitete Tabelle notwendig ist, damit die Verarbeitung von Tabelle 3 fortgesetzt wird.

Answer 4

Je nach Verfügbarkeit von Statistiken und Indizes für die Tabellen in Frage wird die Abfrage Rewrite-Mechanismus in dem Optimierer entscheiden kann oder nicht Table2 für Datensätze, bei denen val < 100 vor dem Scannen Table1 zu scannen.

In bestimmten Situationen, basierend auf demografischen Daten, Joins, Indizierung und Statistiken, stellen Sie möglicherweise fest, dass das Optimierungsprogramm keine Datensätze im Abfrageplan eliminiert, wenn Sie dies für erforderlich halten. Selbst wenn Sie eine abgeleitete Tabelle wie die in Ihrem Beispiel haben. Sie können erzwingen, dass der Optimierer eine abgeleitete Tabelle verarbeitet, indem Sie einfach einen GROUP BY in die abgeleitete Tabelle einfügen. Das Optimierungsprogramm ist dann verpflichtet, das GROUP BY-Aggregat aufzulösen, bevor es in Betracht zieht, den Join zwischen den beiden Tabellen in Ihrem Beispiel zu lösen.

SELECT table1.id, table3.val 
FROM table1 
INNER JOIN (
    SELECT table2.id, tabl2.val 
    FROM table2 
    WHERE val<100 
    GROUP BY 1,2 
) table3 
ON table1.id=table3.id 

Dies ist nicht zu sagen, dass Ihre Standard-Ansatz sollte mit diesem durch Ihren Code ausgeführt werden. Dies ist in der Regel einer meiner letzten Zufluchtsorte, wenn ich einen Abfrageplan habe, der überflüssige Datensätze nicht früher genug im Plan löscht und dazu führt, dass zu viele Daten gescannt und durch die verschiedenen SPOOL-Dateien transportiert werden. Dies ist einfach eine Technik, die Sie in Ihrem Toolkit verwenden können, wenn Sie auf eine solche Situation stoßen.

Der Mechanismus zum Neuschreiben von Abfragen wird von einem Release zum nächsten fortlaufend aktualisiert. Die Details zur Funktionsweise finden Sie in der Datei SQL Transaction Processing Manual für Teradata 13.0.