Explizite oder implizite SQL-Verknüpfungen

Gibt es einen Effizienzunterschied zwischen einer expliziten und einer impliziten inneren Verknüpfung? Zum Beispiel:

SELECT * FROM
table a INNER JOIN table b
ON a.id = b.id;

vs.

SELECT a.*, b.*
FROM table a, table b
WHERE a.id = b.id;

In Bezug auf die Leistung sind sie genau gleich (zumindest in SQL Server).

PS: Beachten Sie, dass die IMPLICIT OUTER JOINSyntax seit SQL Server 2005 veraltet ist. (Die IMPLICIT INNER JOINin der Frage verwendete Syntax wird weiterhin unterstützt.)

Verfall der "Old Style" JOIN-Syntax: Nur eine teilweise Sache

Persönlich bevorzuge ich die Join-Syntax, da dadurch klarer wird, dass die Tabellen verbunden sind und wie sie verbunden werden. Versuchen Sie, größere SQL-Abfragen zu vergleichen, bei denen Sie aus 8 verschiedenen Tabellen auswählen und im Wo viel gefiltert haben. Mithilfe der Verknüpfungssyntax trennen Sie die Teile, in denen die Tabellen verknüpft sind, von dem Teil, in dem Sie die Zeilen filtern.

Unter MySQL 5.1.51 haben beide Abfragen identische Ausführungspläne:

mysql> explain select * from table1 a inner join table2 b on a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.02 sec)

mysql> explain select * from table1 a, table2 b where a.pid = b.pid;
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
| id | select_type | table | type | possible_keys | key  | key_len | ref          | rows | Extra |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
|  1 | SIMPLE      | b     | ALL  | PRIMARY       | NULL | NULL    | NULL         |  986 |       |
|  1 | SIMPLE      | a     | ref  | pid           | pid  | 4       | schema.b.pid |   70 |       |
+----+-------------+-------+------+---------------+------+---------+--------------+------+-------+
2 rows in set (0.00 sec)

table1hat 166208 Zeilen; table2hat ungefähr 1000 Zeilen.

Dies ist ein sehr einfacher Fall; Es beweist keineswegs, dass das Abfrageoptimierungsprogramm nicht verwirrt wird und in einem komplizierteren Fall unterschiedliche Pläne generiert.

Die zweite Syntax bietet die unerwünschte Möglichkeit eines Cross-Joins: Sie können dem FROM-Teil Tabellen hinzufügen, ohne die entsprechende WHERE-Klausel zu verwenden. Dies wird als schädlich angesehen.

Die erste Antwort, die Sie gegeben haben, verwendet die sogenannte ANSI-Join-Syntax, die andere ist gültig und funktioniert in jeder relationalen Datenbank.

Ich stimme grom zu, dass Sie die ANSI-Join-Syntax verwenden sollten. Wie gesagt, der Hauptgrund ist die Klarheit. Anstatt eine where-Klausel mit vielen Prädikaten zu haben, von denen einige Verknüpfungstabellen und andere die mit der ANSI-Verknüpfungssyntax zurückgegebenen Zeilen einschränken, machen Sie blind klar, welche Bedingungen zum Verknüpfen Ihrer Tabellen verwendet werden und welche zum Einschränken der Ergebnisse.

In Bezug auf die Leistung sind sie genau gleich (zumindest in SQL Server). Beachten Sie jedoch, dass diese Join-Syntax nicht mehr unterstützt wird und von SQL Server 2005 nicht sofort unterstützt wird.

Ich denke, Sie denken an die veralteten Operatoren * = und = * im Vergleich zu "Outer Join".

Ich habe gerade die beiden angegebenen Formate getestet und sie funktionieren ordnungsgemäß in einer SQL Server 2008-Datenbank. In meinem Fall ergaben sie identische Ausführungspläne, aber ich konnte nicht sicher sagen, dass dies immer wahr sein würde.

@lomaxx: Zur Verdeutlichung bin ich mir ziemlich sicher, dass beide oben genannten Syntaxen von SQL Serv 2005 unterstützt werden. Die folgende Syntax wird jedoch NICHT unterstützt

select a.*, b.*  
from table a, table b  
where a.id *= b.id;

Insbesondere wird der äußere Join (* =) nicht unterstützt.

Bei einigen Datenbanken (insbesondere Oracle) kann die Reihenfolge der Verknüpfungen einen großen Unterschied für die Abfrageleistung bedeuten (wenn mehr als zwei Tabellen vorhanden sind). Bei einer Anwendung hatten wir in einigen Fällen buchstäblich zwei Größenordnungen Unterschied. Durch die Verwendung der inneren Join-Syntax können Sie dies steuern - wenn Sie die richtige Hinweissyntax verwenden.

Sie haben nicht angegeben, welche Datenbank Sie verwenden, aber die Wahrscheinlichkeit schlägt SQL Server oder MySQL vor, wo es keinen wirklichen Unterschied macht.

Wie Leigh Caldwell festgestellt hat, kann das Abfrageoptimierungsprogramm verschiedene Abfragepläne erstellen, die darauf basieren, wie dieselbe SQL-Anweisung funktional aussieht. Weitere Informationen hierzu finden Sie in den folgenden beiden Blogeinträgen: -

Ein Beitrag des Oracle Optimizer-Teams

Ein weiterer Beitrag aus dem Blog "Structured Data"

Ich hoffe du findest das interessant.

In Bezug auf die Leistung sollte es keinen Unterschied machen. Die explizite Join-Syntax erscheint mir sauberer, da sie die Beziehungen zwischen Tabellen in der from-Klausel klar definiert und die where-Klausel nicht überladen.

Grundsätzlich besteht der Unterschied zwischen den beiden darin, dass einer auf die alte Art und Weise geschrieben ist, während der andere auf die moderne Art und Weise geschrieben ist. Persönlich bevorzuge ich das moderne Skript mit den inneren, linken, äußeren und rechten Definitionen, da diese erklärender sind und den Code besser lesbar machen.

Wenn es um innere Verknüpfungen geht, gibt es auch keinen wirklichen Unterschied in der Lesbarkeit. Es kann jedoch kompliziert werden, wenn Sie sich mit linken und rechten Verknüpfungen befassen, da Sie bei der älteren Methode ungefähr Folgendes erhalten würden:

SELECT * 
FROM table a, table b
WHERE a.id = b.id (+);

Das Obige ist die alte Art und Weise, wie eine linke Verknüpfung geschrieben wird, im Gegensatz zu der folgenden:

SELECT * 
FROM table a 
LEFT JOIN table b ON a.id = b.id;

Wie Sie visuell sehen können, macht die moderne Art und Weise, wie das Skript geschrieben wird, die Abfrage besser lesbar. (Übrigens gilt das Gleiche für rechte Verknüpfungen und etwas komplizierter für äußere Verknüpfungen).

Zurück zur Kesselplatte: Für den SQL-Compiler spielt es keine Rolle, wie die Abfrage geschrieben wird, da sie auf die gleiche Weise behandelt wird. Ich habe eine Mischung aus beidem in Oracle-Datenbanken gesehen, in die viele ältere und jüngere Leute geschrieben haben. Auch hier kommt es darauf an, wie lesbar das Skript ist und mit welchem ​​Team Sie sich entwickeln.

Nach meiner Erfahrung führt die Verwendung der Cross-Join-with-a-where-Klausel-Syntax häufig zu einem gehirngeschädigten Ausführungsplan, insbesondere wenn Sie ein Microsoft SQL-Produkt verwenden. Die Art und Weise, wie SQL Server beispielsweise versucht, die Anzahl der Tabellenzeilen zu schätzen, ist schrecklich. Durch die Verwendung der inneren Join-Syntax können Sie steuern, wie die Abfrage ausgeführt wird. Aus praktischer Sicht muss man sich angesichts des atavistischen Charakters der aktuellen Datenbanktechnologie für den inneren Join entscheiden.