Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

SQL: Datenbankabfragen beschleunigen

Geschwindigkeitsunterschiede bei Unterabfragen

Testen Sie unsere 2017 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Unterabfragen bieten manchmal vergleichbare Ergebnisse, beispielsweise zu Inner Joins, oder ganz neue Lösungen, die ohne sie nicht machbar wären. Allerdings gibt es erhebliche Geschwindigkeitsunterschiede.

Transkript

Sicherlich ist Ihnen diese Art der Schreibweise geläufig mit einem Inner-Join, wenn Sie die Haupt- und Untertabelle miteinander verknüpfen wollen. Das sieht dann in der Entwurfs-Ansicht so aus. Da gibt es eine Verbindungs-Linie zwischen Fremd-Schlüssel und Primär-Schlüssel. Und Sie kriegen, da ich hier nur die viele Daten Seite dartellen lasse, alle Daten, die hier Unterdaten haben. Das lässt sich fast genau so lösen mit einer Unterabfrage. Das sieht dann so aus. Wo es keinen Inner-Join gibt, sondern wo ich für das Verbindungs- Feld prüfe, ob es da auf der Gegenseite einen Datensatz gibt und welchen. Das sieht dann im Entwurf so aus, dass die Untertabelle, die sich hier oben bisher befand, in ein Kriterium hinein gewandert ist, also hier unten steht. Das fühlt sich erst einmal identisch an. Aber wenn Sie einmal auf die Menge der Daten achten. Der Inner-Join liefert 195.000 Datensätze. Und die Unterabfrage liefert nur 152.000 Datensätze. Dieser Unterschied resultiert daraus, dass die Formulierung in den Abfragen ein ganz kleines bisschen unterschiedlich ist. Hier sage ich nämlich, ich möchte gerne alle Daten sehen, die ein Gegenstück haben, deren ID dort existiert. Es gibt also in der Haupttabelle Datensätze und wenn die ein Gegenstück haben, dann werden sie angezeigt. In dem Inner-Join verlange ich aber, dass alle Daten aus der Haupttabelle mit ihrem Gegenstück aus der Untertabelle angezeigt werden können. Selbst wenn Sie das jetzt nicht machen. Wenn Sie sich die Daten angucken, dann werden Sie dort Duplikate finden. Also beispielsweise hier schon das erste. Dieser Haupt-Datensatz hat offensichtlich zwei Datensätze zugehörig. Deswegen wird er hier doppelt angezeigt. Um das zu verhindern und, um hier auch die 152.000 Datensätze zu sehen, muss ich hier die Duplikate wieder rausschmeißen. Beispielsweise mit dem DISTINCT Schlüsselwort. Dann bekommen Sie zwar die gewünschten 152.000 Datensätze, aber Sie merken schon, es dauert deutlich länger. Das DISTINCT muss natürlich Duplikate finden und das kostet immer enorm viel Zeit. Wenn ich mich also hier um Unterabfragen kümmere, dann muss ich aufpassen, dass die wirklich das gleiche liefern. Aber die Unterabfragen sind so vielseitig, dass ich mich an manchen Stellen wundere, wie wenig die normalen Datenbanken offenbar eingesetzt werden. Und die scheinen auch sehr viel schneller zu sein. Wenn Sie also die Chance haben, dann beschäftigen Sie sich einmal mit den Unter Anfragen. Dieses war, so zu sagen, der normale Inner-Join. Im Vergleich dazu die Unter- Abfrage mit einem IN. Es gibt aber nicht nur das IN- Schlüsselwort, was mit Abstand das am häufigsten benutzte ist, sondern es gibt auch ein ANY. Es gibt übrigens auch ein SOME. SOME und ANY sind identisch, insofern kann man das ignorieren. Und es gibt, sehr wichtig, und Sie werden es feststellen, durchaus schnell, ein EXISTS. Das bedeutet, die Unter- Abfrage ist schon so zu sagen fertig, wenn es irgend einen Treffer gibt. Es interessiert mit gar nicht, wie viele Treffer und welche das sind, sondern es reicht, dass es einen Treffer gibt. Allerdings muss ich dafür in der Untertabelle hier einen Filter einbauen, der sich mit einem Feld der Haupt Tabelle beschäftigt. Das könnte wieder Zeit kosten. Da müssen wir einmal gucken. Und dann natürlich mein Liebling wieder hier. Das NOT EXISTS. Das könnte wieder viel Zeit kosten. Und das kann man in einer anderen Schreibweise auch einmal probieren =FALSE und testen, ob das vielleicht schneller ist. Und schließlich noch das NOT IN. Auch das muss ja noch funktionieren, wenn man die Gegenseite braucht, welches möglicherweise über einen Outer-Join über einem NULL zu lösen ist. Also diese Unter Anfragen sind sehr vielseitig und dadurch gibt es auch viel zu testen. Fangen wir also an mit dem ersten Unterschied zwischen einem IN irgendeiner Liste oder =ANY solch einer Liste. Ich hatte schon gesagt, das SOME und das ANY sind identisch. Das IN liefert die Daten in 360 ms zurück. Und SOME, bzw. ANY auch. Es gibt also überhaupt keinen Unterschied. Das sind exakt 100 %. Das wird besser, wenn Sie beispielsweise ANY mit EXISTS vergleichen. Selbst EXISTS zwangsläufig einen Filter haben muss. Das ANY dautert immer noch 360 ms. Aber EXISTS ist schon in 219 ms fertig. Und damit eine Beschleunigung auf 61 %. Das lohnt sich. Was wieder problematisch ist, wenn Sie das EXISTS, was ja schön schnell ist, mit seinem Gegenteil versuchen, also einem NOT EXISTS, dann verlieren Sie wieder rapide Geschwindigkeit. Statt der 219 ms geht es auf 844 ms. Man muss eigentlich sagen runter. Die Zahl wird größer, aber der Erfolg wird schlechter. Es dauert also knapp viermal so lang - 385 %. Und das andere Gegenstück, also zu dem NOT EXISTS, das NOT IN, hätte ich Ihnen gerne ausgemessen. Aber wenn Sie Datenmengen in dieser Größenordnung, ich sage einmal nur 275.000 Datensätze haben, dann bringen Sie damit ziemlich jeden Rechner zum Absturz. Access arbeitet daran mehrere Stunden und kommt nicht zu einem Ergebnis. Ich kann Ihnen also versprechen, es wird katastrophal sein. Nach mehreren Minuten möchte man keine Datenzugriffe mehr sehen. Sie können das beschränken bis 120.000 Datensätze. Dann kann man noch Ergebnisse haben. Aber das ist normalerweise nicht sinnvoll, dass die Befehle nur bis zu einer bestimmten Größenordnung funktionieren. Also das NOT IN ist so schlecht, dass Sie überhaupt nicht drüber nachdenken sollten. Dann können wir noch eine Unterabfrage mit einem Outer-Join vergleichen. Denn eine Unterabfrage mit NOT EXISTS könnte man auch in einem Outer-Join mit einem NULL-Filter lösen. Da ist die Unterabfrage bedeutet schneller. Das NOT EXISTS, obwohl das NOT da drin steckt, braucht zwar 844 ms, aber das Outer-Join  mit dem NULL-Filter über 1,2 Sekunden. Das ist eine Verschlechterung auf 148 %. Das lohnt sich also, statt in Outer-Joins, oder Inner-Joins, je nachdem was an Aufgaben haben, zu denken, auch mal sich mit Unter- Abfragen zu beschäftigen. Da ist Geschwindigkeits- Optimierung möglich.

SQL: Datenbankabfragen beschleunigen

Entdecken Sie, wo das Beschleunigungspotenzial für SQL-Datenbanken liegt und lernen Sie die Rezepte für bessere Performance.

2 Std. 15 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:25.03.2015

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!