Es hängt wirklich davon ab, ich hatte Situationen, in denen ich einige Abfragen durch die Verwendung von Unterabfragen verbessert habe.
Die Faktoren, die mir bekannt sind, sind:
- ob die Unterabfrage Felder aus der äußeren Abfrage zum Vergleich verwendet oder nicht (korreliert oder nicht)
- wenn die Beziehung zwischen der äußeren Abfrage und der Unterabfrage durch Indizes abgedeckt ist
- Wenn es keine verwendbaren Indizes für die Joins gibt und die Unterabfrage nicht korreliert ist und ein kleines Ergebnis zurückgibt, ist es möglicherweise schneller, sie zu verwenden
- Ich bin auch auf Situationen gestoßen, in denen ich eine Abfrage, die order by verwendet, in eine Abfrage umwandelt, die sie nicht verwendet, und sie dann in eine einfache Unterabfrage und Sortierung umwandelt, die die Leistung in mysql verbessert
Wie auch immer, es ist immer gut, verschiedene Varianten zu testen (bitte mit SQL_NO_CACHE), und korrelierte Abfragen in Joins umzuwandeln, ist eine gute Praxis.
Ich würde sogar so weit gehen, es als eine sehr nützliche Praxis zu bezeichnen.
Wenn Ihnen zuerst korrelierte Abfragen in den Sinn kommen, denken Sie womöglich nicht primär an Mengenoperationen, sondern primär an prozedurale Operationen und es ist bei relationalen Datenbanken sehr sinnvoll, die Menge vollständig zu übernehmen Perspektive auf das Datenmodell und Transformationen darauf.
BEARBEITEN:Prozedural vs. relational
Das Denken in Bezug auf Mengenoperationen und Prozeduren läuft auf die Äquivalenz in einigen mengenalgebraischen Ausdrücken hinaus, zum Beispiel ist die Auswahl auf einer Vereinigung äquivalent zur Vereinigung von Auswahlen. Es gibt keinen Unterschied zwischen den beiden.
Aber wenn Sie die beiden Verfahren vergleichen, z. B. die Auswahlkriterien auf jedes Element einer Vereinigung anwenden, indem Sie eine Vereinigung erstellen und dann eine Auswahl anwenden, sind die beiden deutlich unterschiedliche Verfahren, was möglicherweise der Fall ist haben sehr unterschiedliche Eigenschaften (z. B. Auslastung von CPU, I/O, Speicher).
Die Idee hinter relationalen Datenbanken ist, dass Sie nicht versuchen zu beschreiben, wie Sie das Ergebnis (Verfahren) erhalten, sondern nur das, was Sie wollen, und dass das Datenbankverwaltungssystem über den besten Weg (Verfahren) entscheidet, um Ihre Anforderung zu erfüllen. Aus diesem Grund wird SQL Sprache der 4. Generation (4GL) genannt .
Einer der Tricks, die Ihnen dabei helfen, besteht darin, sich daran zu erinnern, dass Tupel keine inhärente Ordnung haben (Mengenelemente sind ungeordnet). Ihr Modell den Problemraum gut darstellt, oder mit anderen Worten, wenn die Bedeutung, die mit dem Namen Ihrer Tabellen und Beziehungen verbunden ist, richtig gemacht wird, oder mit anderen Worten, wenn Ihre Datenbank gut gestaltet ist).
Daher müssen Sie nicht darüber nachdenken, wie, nur was.
In Ihrem Fall war es nur eine Präferenz gegenüber korrelierten Abfragen, also kann es sein, dass ich Ihnen nichts Neues erzähle, aber Sie haben diesen Punkt betont, daher der Kommentar.
Ich denke, wenn Sie sich mit all den Regeln, die Abfragen von einer Form in eine andere umwandeln, vollkommen wohl fühlen (Regeln wie Verteilungsfähigkeit), dass Sie korrelierte Unterabfragen nicht bevorzugen würden (dass Sie alle Formen als gleich ansehen würden).
(Hinweis:oben wird der theoretische Hintergrund erörtert, der für das Datenbankdesign wichtig ist; praktisch weichen die obigen Konzepte ab - nicht alle äquivalenten Umschreibungen einer Abfrage werden notwendigerweise so schnell ausgeführt, geclusterte Primärschlüssel führen dazu, dass Tabellen eine erbliche Reihenfolge auf der Festplatte usw. haben ... aber diese Abweichungen sind nur Abweichungen; die Tatsache, dass nicht alle äquivalenten Abfragen so schnell ausgeführt werden, ist eine Unvollkommenheit des eigentlichen DBMS und nicht der dahinter stehenden Konzepte)
