Join vs. Sub-Query

Ich bin ein MySQL-Benutzer der alten Schule und habe immer eine Unterabfrage vorgezogen JOIN. Aber heutzutage verwendet jeder eine Unterabfrage, und ich hasse es; Ich weiß nicht warum.

Mir fehlt das theoretische Wissen, um selbst zu beurteilen, ob es einen Unterschied gibt. Ist eine Unterabfrage so gut wie eine JOINund gibt es daher keinen Grund zur Sorge?

Entnommen aus dem MySQL-Handbuch ( 13.2.10.11 Umschreiben von Unterabfragen als Joins ):

Ein LEFT [OUTER] JOIN kann schneller sein als eine entsprechende Unterabfrage, da der Server sie möglicherweise besser optimieren kann - eine Tatsache, die nicht nur für MySQL Server gilt.

Unterabfragen können also langsamer sein als LEFT [OUTER] JOIN, aber meiner Meinung nach ist ihre Stärke etwas besser lesbar .

Unterabfragen sind der logisch korrekte Weg, um Probleme des Formulars "Fakten von A abrufen, abhängig von Fakten von B" zu lösen. In solchen Fällen ist es logischer, B in eine Unterabfrage zu stecken, als einen Join durchzuführen. In praktischer Hinsicht ist dies auch sicherer, da Sie nicht vorsichtig sein müssen, wenn Sie aufgrund mehrerer Spiele gegen B doppelte Fakten von A erhalten.

In der Praxis kommt die Antwort jedoch normalerweise auf die Leistung an. Einige Optimierer saugen Zitronen, wenn sie einen Join gegen eine Unterabfrage erhalten, und andere saugen Zitronen in die andere Richtung. Dies ist optimiererspezifisch, DBMS-version-spezifisch und abfragespezifisch.

Historisch gesehen gewinnen explizite Verknüpfungen normalerweise, daher ist die etablierte Weisheit, dass Verknüpfungen besser sind, aber Optimierer werden immer besser. Daher schreibe ich Abfragen lieber zuerst auf logisch kohärente Weise und restrukturiere sie dann, wenn Leistungsbeschränkungen dies rechtfertigen.

In den meisten Fällen sind JOINs schneller als Unterabfragen und es ist sehr selten, dass eine Unterabfrage schneller ist.

In JOINs kann RDBMS einen Ausführungsplan erstellen, der für Ihre Abfrage besser geeignet ist, und vorhersagen, welche Daten zur Verarbeitung geladen werden sollen, und Zeit sparen, im Gegensatz zu der Unterabfrage, bei der alle Abfragen ausgeführt und alle Daten für die Verarbeitung geladen werden .

Das Gute an Unterabfragen ist, dass sie besser lesbar sind als JOINs: Deshalb bevorzugen die meisten neuen SQL-Benutzer sie. es ist der einfache Weg; Aber wenn es um Leistung geht, sind JOINS in den meisten Fällen besser, obwohl sie auch nicht schwer zu lesen sind.

Verwenden Sie EXPLAIN, um zu sehen, wie Ihre Datenbank die Abfrage für Ihre Daten ausführt. In dieser Antwort steckt ein riesiges "es kommt darauf an" ...

PostgreSQL kann eine Unterabfrage in einen Join oder einen Join in eine Unterabfrage umschreiben, wenn es glaubt, dass eine schneller als die andere ist. Es hängt alles von den Daten, Indizes, Korrelationen, Datenmengen, Abfragen usw. ab.

Im Jahr 2010 wäre ich dem Autor dieser Fragen beigetreten und hätte stark dafür gestimmt JOIN, aber mit viel mehr Erfahrung (insbesondere in MySQL) kann ich sagen: Ja, Unterabfragen können besser sein. Ich habe hier mehrere Antworten gelesen. Einige der angegebenen Unterabfragen sind schneller, aber es fehlte eine gute Erklärung. Ich hoffe, ich kann einem diese (sehr) späte Antwort geben:

Lassen Sie mich zunächst das Wichtigste sagen: Es gibt verschiedene Formen von Unterabfragen

Und die zweite wichtige Aussage: Größe ist wichtig

Wenn Sie Unterabfragen verwenden, sollten Sie wissen, wie der DB-Server die Unterabfrage ausführt. Besonders wenn die Unterabfrage einmal oder für jede Zeile ausgewertet wird! Auf der anderen Seite kann ein moderner DB-Server viel optimieren. In einigen Fällen hilft eine Unterabfrage bei der Optimierung einer Abfrage, aber eine neuere Version des DB-Servers kann die Optimierung überflüssig machen.

Unterabfragen in Auswahlfeldern

SELECT moo, (SELECT roger FROM wilco WHERE moo = me) AS bar FROM foo

Beachten Sie, dass für jede resultierende Zeile aus eine Unterabfrage ausgeführt wird foo.
Vermeiden Sie dies wenn möglich; Dies kann Ihre Abfrage bei großen Datenmengen drastisch verlangsamen. Wenn die Unterabfrage jedoch keinen Verweis darauf foohat, kann sie vom DB-Server als statischer Inhalt optimiert und nur einmal ausgewertet werden.

Unterabfragen in der Where-Anweisung

SELECT moo FROM foo WHERE bar = (SELECT roger FROM wilco WHERE moo = me)

Wenn Sie Glück haben, optimiert die DB dies intern in eine JOIN. Wenn nicht, wird Ihre Abfrage bei großen Datenmengen sehr, sehr langsam, da die Unterabfrage für jede Zeile ausgeführt wird foo, nicht nur für die Ergebnisse wie beim Auswahltyp.

Unterabfragen in der Join-Anweisung

SELECT moo, bar 
  FROM foo 
    LEFT JOIN (
      SELECT MIN(bar), me FROM wilco GROUP BY me
    ) ON moo = me

Das ist interessant. Wir kombinieren JOINmit einer Unterabfrage. Und hier bekommen wir die wahre Stärke von Unterabfragen. Stellen Sie sich einen Datensatz mit Millionen von Zeilen vor, wilcoaber nur wenigen unterschiedlichen me. Anstatt sich gegen einen riesigen Tisch anzumelden, haben wir jetzt einen kleineren temporären Tisch, gegen den wir uns anmelden können. Dies kann je nach Datenbankgröße zu viel schnelleren Abfragen führen. Sie können den gleichen Effekt mit CREATE TEMPORARY TABLE ...und erzielen INSERT INTO ... SELECT ..., was möglicherweise zu einer besseren Lesbarkeit bei sehr komplexen Abfragen führt (Sie können jedoch Datensätze in einer wiederholbaren Leseisolationsstufe sperren).

Verschachtelte Unterabfragen

SELECT moo, bar
  FROM (
    SELECT moo, CONCAT(roger, wilco) AS bar
      FROM foo
      GROUP BY moo
      HAVING bar LIKE 'SpaceQ%'
  ) AS temp_foo
  ORDER BY bar

Sie können Unterabfragen in mehreren Ebenen verschachteln. Dies kann bei großen Datenmengen hilfreich sein, wenn Sie die Ergebnisse gruppieren oder sortieren müssen. Normalerweise erstellt der DB-Server hierfür eine temporäre Tabelle, aber manchmal müssen Sie nicht die gesamte Tabelle sortieren, sondern nur die Ergebnismenge. Dies kann je nach Größe der Tabelle zu einer viel besseren Leistung führen.

Fazit

Unterabfragen sind kein Ersatz für a JOINund Sie sollten sie nicht so verwenden (obwohl möglich). Meiner bescheidenen Meinung nach ist die korrekte Verwendung einer Unterabfrage die Verwendung als schneller Ersatz für CREATE TEMPORARY TABLE .... Eine gute Unterabfrage reduziert ein Dataset auf eine Weise, die Sie in einer ONAnweisung von a nicht erreichen können JOIN. Wenn eine Unterabfrage eines der Schlüsselwörter hat GROUP BYoder DISTINCTsich vorzugsweise nicht in den Auswahlfeldern oder in der where-Anweisung befindet, kann dies die Leistung erheblich verbessern.

Um die beiden zuerst zu vergleichen, sollten Sie zunächst Abfragen mit Unterabfragen unterscheiden, um:

1. Eine Klasse von Unterabfragen, für die immer entsprechende äquivalente Abfragen mit Joins geschrieben wurden
2. Eine Klasse von Unterabfragen, die nicht mithilfe von Joins neu geschrieben werden können

Für die erste Klasse von Abfragen sieht ein gutes RDBMS Verknüpfungen und Unterabfragen als gleichwertig und erzeugt dieselben Abfragepläne.

Heutzutage macht das sogar MySQL.

Manchmal ist dies jedoch nicht der Fall, aber dies bedeutet nicht, dass Joins immer gewinnen. Ich hatte Fälle, in denen Unterabfragen in MySQL die Leistung verbesserten. (Wenn beispielsweise etwas den MySQL-Planer daran hindert, die Kosten korrekt zu schätzen, und der Planer die Join-Variante und die Unterabfrage-Variante nicht als gleich ansieht, können Unterabfragen die Joins übertreffen, indem sie einen bestimmten Pfad erzwingen.)

Die Schlussfolgerung ist, dass Sie Ihre Abfragen sowohl für Join- als auch für Unterabfragevarianten testen sollten, wenn Sie sicher sein möchten, welche Variante eine bessere Leistung erbringt.

Für die zweite Klasse macht der Vergleich keinen Sinn, da diese Abfragen nicht mithilfe von Joins neu geschrieben werden können. In diesen Fällen sind Unterabfragen eine natürliche Methode, um die erforderlichen Aufgaben auszuführen, und Sie sollten sie nicht diskriminieren.

Ich denke, was in den zitierten Antworten unterbetont wurde, ist das Problem von Duplikaten und problematischen Ergebnissen, die sich aus bestimmten (Anwendungs-) Fällen ergeben können.

(obwohl Marcelo Cantos es erwähnt)

Ich werde das Beispiel aus Stanfords Lagunita-Kursen zu SQL zitieren.

Schülertisch

+------+--------+------+--------+
| sID  | sName  | GPA  | sizeHS |
+------+--------+------+--------+
|  123 | Amy    |  3.9 |   1000 |
|  234 | Bob    |  3.6 |   1500 |
|  345 | Craig  |  3.5 |    500 |
|  456 | Doris  |  3.9 |   1000 |
|  567 | Edward |  2.9 |   2000 |
|  678 | Fay    |  3.8 |    200 |
|  789 | Gary   |  3.4 |    800 |
|  987 | Helen  |  3.7 |    800 |
|  876 | Irene  |  3.9 |    400 |
|  765 | Jay    |  2.9 |   1500 |
|  654 | Amy    |  3.9 |   1000 |
|  543 | Craig  |  3.4 |   2000 |
+------+--------+------+--------+

Tabelle anwenden

(Bewerbungen an bestimmten Universitäten und Hauptfächern)

+------+----------+----------------+----------+
| sID  | cName    | major          | decision |
+------+----------+----------------+----------+
|  123 | Stanford | CS             | Y        |
|  123 | Stanford | EE             | N        |
|  123 | Berkeley | CS             | Y        |
|  123 | Cornell  | EE             | Y        |
|  234 | Berkeley | biology        | N        |
|  345 | MIT      | bioengineering | Y        |
|  345 | Cornell  | bioengineering | N        |
|  345 | Cornell  | CS             | Y        |
|  345 | Cornell  | EE             | N        |
|  678 | Stanford | history        | Y        |
|  987 | Stanford | CS             | Y        |
|  987 | Berkeley | CS             | Y        |
|  876 | Stanford | CS             | N        |
|  876 | MIT      | biology        | Y        |
|  876 | MIT      | marine biology | N        |
|  765 | Stanford | history        | Y        |
|  765 | Cornell  | history        | N        |
|  765 | Cornell  | psychology     | Y        |
|  543 | MIT      | CS             | N        |
+------+----------+----------------+----------+

Versuchen wir, die GPA-Ergebnisse für Studenten zu finden, die sich für ein CSHauptfach beworben haben (unabhängig von der Universität).

Verwenden einer Unterabfrage:

select GPA from Student where sID in (select sID from Apply where major = 'CS');

+------+
| GPA  |
+------+
|  3.9 |
|  3.5 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

Der Durchschnittswert für diese Ergebnismenge ist:

select avg(GPA) from Student where sID in (select sID from Apply where major = 'CS');

+--------------------+
| avg(GPA)           |
+--------------------+
| 3.6800000000000006 |
+--------------------+

Verwenden eines Joins:

select GPA from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+------+
| GPA  |
+------+
|  3.9 |
|  3.9 |
|  3.5 |
|  3.7 |
|  3.7 |
|  3.9 |
|  3.4 |
+------+

Durchschnittswert für diese Ergebnismenge:

select avg(GPA) from Student, Apply where Student.sID = Apply.sID and Apply.major = 'CS';

+-------------------+
| avg(GPA)          |
+-------------------+
| 3.714285714285714 |
+-------------------+

Es ist offensichtlich, dass der zweite Versuch in unserem Anwendungsfall zu irreführenden Ergebnissen führt, da für die Berechnung des Durchschnittswerts Duplikate gezählt werden. Es ist auch offensichtlich, dass die Verwendung von distinctmit der join-basierten Anweisung das Problem nicht beseitigt, da fälschlicherweise eines von drei Vorkommen der 3.9Punktzahl beibehalten wird. Der richtige Fall besteht darin, ZWEI (2) Vorkommen der 3.9Punktzahl zu berücksichtigen, vorausgesetzt , wir haben tatsächlich ZWEI (2) Schüler mit dieser Punktzahl, die unseren Abfragekriterien entsprechen.

In einigen Fällen scheint eine Unterabfrage neben Leistungsproblemen der sicherste Weg zu sein.

In der MSDN-Dokumentation für SQL Server heißt es

Viele Transact-SQL-Anweisungen, die Unterabfragen enthalten, können alternativ als Verknüpfungen formuliert werden. Andere Fragen können nur mit Unterabfragen gestellt werden. In Transact-SQL gibt es normalerweise keinen Leistungsunterschied zwischen einer Anweisung, die eine Unterabfrage enthält, und einer semantisch äquivalenten Version, die dies nicht tut. In einigen Fällen, in denen die Existenz überprüft werden muss, führt ein Join jedoch zu einer besseren Leistung. Andernfalls muss die verschachtelte Abfrage für jedes Ergebnis der äußeren Abfrage verarbeitet werden, um die Beseitigung von Duplikaten sicherzustellen. In solchen Fällen würde ein Join-Ansatz zu besseren Ergebnissen führen.

Also, wenn Sie so etwas brauchen

select * from t1 where exists select * from t2 where t2.parent=t1.id

Versuchen Sie stattdessen, join zu verwenden. In anderen Fällen macht es keinen Unterschied.

Ich sage: Das Erstellen von Funktionen für Unterabfragen beseitigt das Problem des Cluttters und ermöglicht es Ihnen, zusätzliche Logik für Unterabfragen zu implementieren. Ich empfehle daher, wann immer möglich Funktionen für Unterabfragen zu erstellen.

Unordnung im Code ist ein großes Problem, und die Industrie arbeitet seit Jahrzehnten daran, es zu vermeiden.

Führen Sie eine sehr große Datenbank von einem alten Mambo-CMS aus:

SELECT id, alias
FROM
  mos_categories
WHERE
  id IN (
    SELECT
      DISTINCT catid
    FROM mos_content
  );

0 Sekunden

SELECT
  DISTINCT mos_content.catid,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

~ 3 Sekunden

Eine EXPLAIN zeigt, dass sie genau die gleiche Anzahl von Zeilen untersuchen, aber eine dauert 3 Sekunden und eine ist fast augenblicklich. Moral der Geschichte? Wenn Leistung wichtig ist (wann nicht?), Probieren Sie es auf verschiedene Arten aus und finden Sie heraus, welche am schnellsten ist.

Und...

SELECT
  DISTINCT mos_categories.id,
  mos_categories.alias
FROM
  mos_content, mos_categories
WHERE
  mos_content.catid = mos_categories.id;

0 Sekunden

Wieder die gleichen Ergebnisse, die gleiche Anzahl der untersuchten Zeilen. Ich vermute, dass DISTINCT mos_content.catid viel länger braucht, um herauszufinden, als DISTINCT mos_categories.id.

Nach meiner Beobachtung wie in zwei Fällen funktioniert der Join schnell, wenn eine Tabelle weniger als 100.000 Datensätze enthält.

Wenn eine Tabelle jedoch mehr als 100.000 Datensätze enthält, ist eine Unterabfrage das beste Ergebnis.

Ich habe eine Tabelle mit 500.000 Datensätzen, die ich unter der Abfrage erstellt habe, und die Ergebniszeit ist wie folgt

SELECT * 
FROM crv.workorder_details wd 
inner join  crv.workorder wr on wr.workorder_id = wd.workorder_id;

Ergebnis: 13,3 Sekunden

select * 
from crv.workorder_details 
where workorder_id in (select workorder_id from crv.workorder)

Ergebnis: 1,65 Sekunden

Unterabfragen werden im Allgemeinen verwendet, um eine einzelne Zeile als atomaren Wert zurückzugeben. Sie können jedoch verwendet werden, um Werte mit mehreren Zeilen mit dem Schlüsselwort IN zu vergleichen. Sie sind an nahezu jedem wichtigen Punkt in einer SQL-Anweisung zulässig, einschließlich der Zielliste, der WHERE-Klausel usw. Eine einfache Unterabfrage kann als Suchbedingung verwendet werden. Zum Beispiel zwischen zwei Tabellen:

   SELECT title FROM books WHERE author_id = (SELECT id FROM authors WHERE last_name = 'Bar' AND first_name = 'Foo');

Beachten Sie, dass für die Verwendung eines Normalwertoperators für die Ergebnisse einer Unterabfrage nur ein Feld zurückgegeben werden muss. Wenn Sie prüfen möchten, ob ein einzelner Wert in einer Reihe anderer Werte vorhanden ist, verwenden Sie IN:

   SELECT title FROM books WHERE author_id IN (SELECT id FROM authors WHERE last_name ~ '^[A-E]');

Dies unterscheidet sich offensichtlich von einem LEFT-JOIN, bei dem Sie nur Inhalte aus Tabelle A und B verknüpfen möchten, auch wenn die Verknüpfungsbedingung keinen passenden Datensatz in Tabelle B usw. findet.

Wenn Sie sich nur Sorgen um die Geschwindigkeit machen, müssen Sie Ihre Datenbank überprüfen und eine gute Abfrage schreiben, um festzustellen, ob es einen signifikanten Leistungsunterschied gibt.

MySQL-Version: 5.5.28-0ubuntu0.12.04.2-log

Ich hatte auch den Eindruck, dass JOIN in MySQL immer besser ist als eine Unterabfrage, aber EXPLAIN ist ein besserer Weg, um ein Urteil zu fällen. Hier ist ein Beispiel, in dem Unterabfragen besser funktionieren als JOINs.

Hier ist meine Anfrage mit 3 Unterabfragen:

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date 
FROM `vote-ranked-listory` vrl 
INNER JOIN lists l ON l.list_id = vrl.list_id 
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION' 
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5 
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=43) IS NULL 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=55) IS NULL 
 AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL 
ORDER BY vrl.moved_date DESC LIMIT 200;

EXPLAIN zeigt:

+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+
| id | select_type        | table    | type   | possible_keys                                       | key          | key_len | ref                                             | rows | Extra                    |
+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+
|  1 | PRIMARY            | vrl      | index  | PRIMARY                                             | moved_date   | 8       | NULL                                            |  200 | Using where              |
|  1 | PRIMARY            | l        | eq_ref | PRIMARY,status,ispublic,idx_lookup,is_public_status | PRIMARY      | 4       | ranker.vrl.list_id                              |    1 | Using where              |
|  1 | PRIMARY            | vrlih    | eq_ref | PRIMARY                                             | PRIMARY      | 9       | ranker.vrl.list_id,ranker.vrl.ontology_id,const |    1 | Using where              |
|  1 | PRIMARY            | lbs      | eq_ref | PRIMARY,idx_list_burial_state,burial_score          | PRIMARY      | 4       | ranker.vrl.list_id                              |    1 | Using where              |
|  4 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
|  3 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
|  2 | DEPENDENT SUBQUERY | list_tag | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.l.list_id,const                          |    1 | Using where; Using index |
+----+--------------------+----------+--------+-----------------------------------------------------+--------------+---------+-------------------------------------------------+------+--------------------------+

Die gleiche Abfrage mit JOINs lautet:

EXPLAIN SELECT vrl.list_id,vrl.ontology_id,vrl.position,l.name AS list_name, vrlih.position AS previous_position, vrl.moved_date 
FROM `vote-ranked-listory` vrl 
INNER JOIN lists l ON l.list_id = vrl.list_id 
INNER JOIN `vote-ranked-list-item-history` vrlih ON vrl.list_id = vrlih.list_id AND vrl.ontology_id=vrlih.ontology_id AND vrlih.type='PREVIOUS_POSITION' 
INNER JOIN list_burial_state lbs ON lbs.list_id = vrl.list_id AND lbs.burial_score < 0.5 
LEFT JOIN list_tag lt1 ON lt1.list_id = vrl.list_id AND lt1.tag_id = 43 
LEFT JOIN list_tag lt2 ON lt2.list_id = vrl.list_id AND lt2.tag_id = 55 
INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403 
WHERE vrl.position <= 15 AND l.status='ACTIVE' AND l.is_public=1 AND vrl.ontology_id < 1000000000 
AND lt1.list_id IS NULL AND lt2.tag_id IS NULL 
ORDER BY vrl.moved_date DESC LIMIT 200;

und die Ausgabe ist:

+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
| id | select_type | table | type   | possible_keys                                       | key          | key_len | ref                                         | rows | Extra                                        |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+
|  1 | SIMPLE      | lt3   | ref    | list_tag_key,list_id,tag_id                         | tag_id       | 5       | const                                       | 2386 | Using where; Using temporary; Using filesort |
|  1 | SIMPLE      | l     | eq_ref | PRIMARY,status,ispublic,idx_lookup,is_public_status | PRIMARY      | 4       | ranker.lt3.list_id                          |    1 | Using where                                  |
|  1 | SIMPLE      | vrlih | ref    | PRIMARY                                             | PRIMARY      | 4       | ranker.lt3.list_id                          |  103 | Using where                                  |
|  1 | SIMPLE      | vrl   | ref    | PRIMARY                                             | PRIMARY      | 8       | ranker.lt3.list_id,ranker.vrlih.ontology_id |   65 | Using where                                  |
|  1 | SIMPLE      | lt1   | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.lt3.list_id,const                    |    1 | Using where; Using index; Not exists         |
|  1 | SIMPLE      | lbs   | eq_ref | PRIMARY,idx_list_burial_state,burial_score          | PRIMARY      | 4       | ranker.vrl.list_id                          |    1 | Using where                                  |
|  1 | SIMPLE      | lt2   | ref    | list_tag_key,list_id,tag_id                         | list_tag_key | 9       | ranker.lt3.list_id,const                    |    1 | Using where; Using index                     |
+----+-------------+-------+--------+-----------------------------------------------------+--------------+---------+---------------------------------------------+------+----------------------------------------------+

Ein Vergleich der rowsSpalte zeigt den Unterschied und die Abfrage mit JOINs wird verwendet Using temporary; Using filesort.

Wenn ich beide Abfragen ausführe, ist die erste in 0,02 Sekunden erledigt, die zweite wird auch nach 1 Minute nicht abgeschlossen, daher hat EXPLAIN diese Abfragen richtig erklärt.

Wenn ich den INNER JOIN nicht auf dem list_tagTisch habe, dh wenn ich entferne

AND (SELECT list_id FROM list_tag WHERE list_id=l.list_id AND tag_id=246403) IS NOT NULL  

ab der ersten Abfrage und entsprechend:

INNER JOIN list_tag lt3 ON lt3.list_id = vrl.list_id AND lt3.tag_id = 246403

Ab der zweiten Abfrage gibt EXPLAIN für beide Abfragen die gleiche Anzahl von Zeilen zurück, und beide Abfragen werden gleich schnell ausgeführt.

Unterabfragen können Aggregationsfunktionen im laufenden Betrieb berechnen. ZB Finden Sie den Mindestpreis des Buches und erhalten Sie alle Bücher, die mit diesem Preis verkauft werden. 1) Verwenden von Unterabfragen:

SELECT titles, price
FROM Books, Orders
WHERE price = 
(SELECT MIN(price)
 FROM Orders) AND (Books.ID=Orders.ID);

2) Verwenden von JOINs

SELECT MIN(price)
     FROM Orders;
-----------------
2.99

SELECT titles, price
FROM Books b
INNER JOIN  Orders o
ON b.ID = o.ID
WHERE o.price = 2.99;

• Eine allgemeine Regel ist, dass Verknüpfungen in den meisten Fällen schneller sind (99%).
• Je mehr Datentabellen vorhanden sind, desto langsamer sind die Unterabfragen .
• Je weniger Datentabellen haben, die Unterabfragen entsprechende Geschwindigkeit haben wie verbindet .
• Die Unterabfragen sind einfacher, verständlicher und leichter zu lesen.
• Die meisten Web- und App-Frameworks sowie deren "ORMs" und "Aktive Datensätze " generieren Abfragen mit Unterabfragen , da mit Unterabfragen die Aufteilung der Verantwortung, das Verwalten von Code usw. einfacher ist.
• Für kleinere Websites oder Apps sind Unterabfragen in Ordnung. Bei größeren Websites und Apps müssen Sie jedoch generierte Abfragen häufig neu schreiben, um Abfragen zu verbinden , insbesondere wenn eine Abfrage viele Unterabfragen in der Abfrage verwendet.

Einige Leute sagen, "einige RDBMS können eine Unterabfrage in einen Join oder einen Join in eine Unterabfrage umschreiben, wenn sie glauben , dass eine schneller als die andere ist.", Aber diese Aussage gilt für einfache Fälle, sicherlich nicht für komplizierte Abfragen mit Unterabfragen, die tatsächlich a verursachen Leistungsprobleme.

Der Unterschied wird nur sichtbar, wenn die zweite Verbindungstabelle wesentlich mehr Daten enthält als die Primärtabelle. Ich hatte eine Erfahrung wie unten ...

Wir hatten eine Benutzertabelle mit einhunderttausend Einträgen und deren Mitgliedschaftsdaten (Freundschaft) von ungefähr dreihunderttausend Einträgen. Es war eine Join-Anweisung, um Freunde und ihre Daten aufzunehmen, aber mit großer Verzögerung. Aber es funktionierte gut, wenn die Mitgliedschaftstabelle nur eine geringe Datenmenge enthielt. Nachdem wir es geändert hatten, um eine Unterabfrage zu verwenden, funktionierte es einwandfrei.

In der Zwischenzeit arbeiten die Join-Abfragen jedoch mit anderen Tabellen, die weniger Einträge als die Primärtabelle haben.

Daher denke ich, dass die Join- und Sub-Query-Anweisungen einwandfrei funktionieren und von den Daten und der Situation abhängen.

Heutzutage können viele Datenbankanbieter Unterabfragen und Verknüpfungen optimieren. Sie müssen Ihre Anfrage also einfach mit EXPLAIN untersuchen und feststellen, welche schneller ist. Wenn es keinen großen Unterschied in der Leistung gibt, bevorzuge ich die Verwendung von Unterabfragen, da diese einfach und leichter zu verstehen sind.

Ich denke nur an das gleiche Problem, aber ich verwende die Unterabfrage im FROM-Teil. Ich muss eine Verbindung herstellen und von großen Tabellen abfragen, die "Slave" -Tabelle hat 28 Millionen Datensätze, aber das Ergebnis sind nur 128, also kleine Ergebnisse, große Datenmengen! Ich benutze die MAX () Funktion darauf.

Erstens verwende ich LEFT JOIN, weil ich denke, dass dies der richtige Weg ist, das MySQL kann sich optimieren usw. Zum zweiten Mal schreibe ich nur zum Testen um, um eine Unterauswahl gegen das JOIN zu treffen.

LEFT JOIN-Laufzeit: 1,12 s SUB-SELECT-Laufzeit: 0,06 s

18 mal schneller die Unterauswahl als der Join! Nur im Chokito Adv. Die Unterauswahl sieht schrecklich aus, aber das Ergebnis ...

Wenn Sie Ihre Abfrage mit join beschleunigen möchten:

Verwenden Sie für "inner join / join" nicht die where-Bedingung, sondern die Bedingung "ON". Z.B:

     select id,name from table1 a  
   join table2 b on a.name=b.name
   where id='123'

 Try,

    select id,name from table1 a  
   join table2 b on a.name=b.name and a.id='123'

Verwenden Sie für "Links / Rechts-Verknüpfung" nicht die Option "EIN", da bei Verwendung der Links / Rechts-Verknüpfung alle Zeilen für eine Tabelle abgerufen werden. Daher wird die Verwendung in "Ein" nicht verwendet. Versuchen Sie also, die Bedingung "Wo" zu verwenden