SELECT * FROM TableA
INNER JOIN TableB
ON TableA.name = TableB.name
SELECT * FROM TableA, TableB
where TableA.name = TableB.name
Welches ist der bevorzugte Weg und warum? Wird es Leistungsunterschiede geben, wenn Keywords wie JOIN verwendet werden?INNER JOIN Schlüsselwörter | mit und ohne sie zu verwenden
Dank
Der zweite Weg ist die klassische Art, es zu tun, bevor das join Schlüsselwort existierte.
Normalerweise generiert der Abfrageprozessor die gleichen Datenbankoperationen aus den beiden Abfragen, sodass die Leistung nicht beeinträchtigt wird.
Die Verwendung von join beschreibt besser, was Sie in der Abfrage tun. Wenn Sie viele Joins haben, ist es auch besser, weil die verbundene Tabelle und ihre Bedingung nebeneinander liegen, anstatt alle Tabellen an einem Ort und alle Bedingungen in einem anderen zu setzen.
Ein weiterer Aspekt ist, dass es einfacher ist, einen ungebundenen Join versehentlich auf die zweite Art auszuführen, was zu einem Cross-Join führt, der alle Kombinationen aus den beiden Tabellen enthält.
herausfinden, indem EXPLAIN SELECT …
deren Verwendung im Motor hängt verwendet, auf den Abfrage-Optimierer, auf den Tasten, auf dem Tisch; auf so ziemlich alles
den ersten verwenden, wie es ist:
Was der Leistung - es soll kein Unterschied.
Sie können auch die Join-Bedingungen (in den ON-Klauseln) von den Filterbedingungen (in der WHERE-Klausel) trennen –
Die meisten aktuellen Datenbanken werden beide Abfragen in den gleichen Ausführungsplan optimieren. Verwenden Sie jedoch die erste Syntax, es ist der aktuelle Standard. Wenn Sie diese Joinsyntax lernen und verwenden, hilft das bei Abfragen mit LEFT OUTER JOIN und RIGHT OUTER JOIN. die mit der älteren Syntax mit den Joins in der WHERE-Klausel schwierig und problematisch werden.
Ich habe festgestellt, dass in einer ordnungsgemäß normalisierten Datenbank der RIGHT Join selten (jemals?) Verwendet werden sollte, in einer denormalisierten Datenbank ist dies jedoch nicht immer der Fall. Ich benutze dies als ein Maß der Notwendigkeit, die Normalisierung/Struktur umzuformen. –
@Mark Schultheiss, siehe diese Frage: http://StackOverflow.com/Questions/689963/does-anyone-use-Right-Outer-Joins –
genau, nur die Reihenfolge der Tabelle ändern wird oft ein Recht machen, einen linken beitreten, was aus meiner Erfahrung ist einfacher in Wartungszyklen, vor allem für Junior-Entwickler –
In einigen SQL-Engines ist die zweite Form (assoziative Joins) deaktiviert. Verwenden Sie das erste Formular.
Sekunde ist weniger explizit, verursacht Beginers zu SQL, um beim Schreiben von Code zu pausieren. Ist viel schwieriger in komplexen SQL aufgrund der Reihenfolge der Join-Match-Anforderung mit der WHERE-Klausel Sequenz zu verwalten - sie (Sequenz im Code) müssen übereinstimmen oder die zurückgegebenen Ergebnisse ändern sich die zurückgegebene Datensatz ändern, was wirklich widerspricht Der Gedanke, dass die Sequenz die Ergebnisse nicht verändern sollte, wenn Elemente auf der gleichen Ebene betrachtet werden.
Wenn Joins erstellt werden, die mehrere Tabellen enthalten, wird es WIRKLICH schwierig, zu programmieren, ziemlich schnell mit dem zweiten Formular.
EDIT: Leistung: Ich denke Codierung, Debugging Leichtigkeit Teil der persönlichen Leistung, damit die Leichtigkeit der Bearbeitung/debug/Wartung ist besser performant mit der ersten Form - es dauert nur weniger Zeit, Sachen während der Entwicklung zu tun und zu verstehen Wartungszyklen.
Nur um klar zu sein, ist die entschärfte Form der '* =' und '= *' auf dem Formular für LINKS und RECHTS nicht das ANSI-Standardkomma für Tabellen getrennt. ..sorry, wenn ich Verwirrung durch diesen Teil hinzugefügt habe :) –
Das Filtern von Joins ausschließlich mit WHERE kann in einigen gängigen Szenarien äußerst ineffizient sein.Zum Beispiel:
SELECT * FROM people p, companies c WHERE p.companyID = c.id AND p.firstName = 'Daniel'
Die meisten Datenbanken werden diese Abfrage ausführen, ganz wörtlich, zunächst das kartesische Produkt der Firmen und Personen Tabellen zu nehmen und dann von denen, Filterung, die passende CompanyID und id Felder haben. Während das vollständig unbeschränkte Produkt nirgendwo außer im Speicher und nur für einen Moment existiert, dauert seine Berechnung einige Zeit.
Ein besserer Ansatz besteht darin, die Einschränkungen mit den JOINs zu gruppieren, wo dies relevant ist. Dies ist nicht nur subjektiv leichter zu lesen, sondern auch wesentlich effizienter. Thusly:
SELECT * FROM people p JOIN companies c ON p.companyID = c.id
WHERE p.firstName = 'Daniel'
Es ist ein wenig länger, aber die Datenbank ist in der Lage auf der ON-Klausel zu suchen und es verwendet, die vollständig mit beschränktem zu berechnen direkt JOIN, anstatt mit allem, was dem Starten und dann Begrenzung nach unten. Dies ist schneller zu berechnen (insbesondere bei großen Datensätzen und/oder Joins mit vielen Tabellen) und erfordert weniger Arbeitsspeicher.
Ich ändere jede Abfrage, die ich sehe, die die "Komma JOIN" -Syntax verwendet. Meiner Meinung nach ist der einzige Zweck für seine Existenz Prägnanz. In Anbetracht der Auswirkungen auf die Leistung halte ich dies nicht für einen zwingenden Grund.
Vereinbart, die erste ist besser für Klarheit und Kontrolle; Es ist einfacher, den Join-Typ zu ändern, wenn Sie möchten. –