SQL INNER JOINs -> Performance Frage

D

d3mueller

Mitglied
Hi, ich habe gerade mit JOINS in SQL angefangen, um normalisierte Datenbanktabellen in einem Query abzurufen.

Ich habe jetzt eine Frage:

Ist es Performance-technisch schlecht, wenn ich in einer SQL-Abfrage irgendwie 10-12 JOINs habe? Weil so viele "Untertabellen" habe ich, wenn ich die Tabelle normalisiere. Also so was:

Tabelle:
research
researchNames
researchCosts
....



Da muss man halt ganz of "JOIN ... ON ... JOIN ... ON ..." machen. Dauert das lange? Z.B. auch, wenn man ganz viele Zeilen auslesen möchte, wenn nicht sogar alle.?

Ich kann es nicht testen, weil ich es momentan nur in der Theorie geplant habe^^. Und bevor ich stundenlang das mühselig erstelle und dann ist es viel zu langsam, frage ich hier mal nach.

Ich habe im Internet gelesen, dass manche irgendwie 5 JOINS in einem Query haben, und dann 100 000 Zeilen auslesen. Und das dauert 5 Minuten. Das ist ganz schön lang.

Gut, ich glaube ich werde bei meinen Dingen nicht 100 000 Zeilen haben. Wenns hoch kommt werdens hundert, und nur bei manchen Tabellen ganz eventuell auch im 4-stelligen Bereich, wobei diese Tabellen dann nicht unbedingt zusammen in einem Query abgerufen werden müssen.

Ich habe außerdem von Indexing gelesen, konnte aber noch nicht so recht verstehen, was genau das ist.


Was meint ihr? Habt ihr damit schon Erfahrung gemacht? Ich würde mich echt über jede Hilfe freuen :)

Viele Grüße,
d3mueller
 
Natürlich ist es schneller, wenn die Datenbank weniger Joins vollziehen muss. Es ist auch schneller wenn man nur eine Spalte anstelle deren 20 ausgeben lässt. Aber das sollte eigentlich kein Argument sein auf Joins zu verzichten.
Man kann aber keine generelle Aussage treffen, ob sowas schnell sein wird oder nicht. Kommt auf vieles darauf an. Die Datenbank, das Datenmodell, die Datentypen, Indexe und nicht zuletzt die Daten selbst.
Es ist aber so, dass Joins die Paradedisziplin jedes DBMS sind. Grundsätzlich ist es aber immer gut für die Join Felder (PK,FK) einen Index zu verwenden. Ein Index ist sowas wie ein Inhaltsverzeichnis für die Datenbank. Und zum Schluss: 100'000 Zeilen ist gar nichts. Wenn wir von einigen Hundert Millionen bis Milliarden Zeilen sprechen muss man sich langsam Gedanken machen.

@admin: move to Relationale Datenbanksysteme
 
Danke :)

Und wie sehen Indexe praktisch aus? Ist das einfach ne eigene Datenbanktabelle mit Indexes und irgendwie dem entsprechenden Speicherort oder so?
 
Danke für die Antworten :D

Noch ein paar Verständnisfragen dazu (sorry, aber ich möchte es gerne verstehen^^):

1. Also sollte man für Tabellen, mit vielen Zeilen, Indexe verwenden? Also wenn man eine Tabelle "researchNames" hat, mit den Spalten "researchID" und "researchName", dann geht das doch so, oder:
Code: 
CREATE INDEX researchNamesIndexes
ON researchNames (researchName)

Dann würde er doch Indexe für die Namens-Spalte dieser Tabelle erstellen. Muss ich dann, wenn ich Daten auslesen will, diese neu erstellte Index-Tabelle nehmen, oder ganz normal
Code: 
SELECT * FROM researchNames



2. Aber bringt das was, wenn ich nicht ganz so viele Zeilen habe?

Habe mal geschaut, in der researchCosts-Tabelle könnten schon so 800-1000 Zeilen eingetragen werden, die ich dann auch alle auslesen muss (wenn man z.B. alle seine Forschungen im Browsergame sehen will und auch wissen will, was der Upgrade kostet). Lohnen sich da Indexe? Weil man in den meisten Fällen (aber eben nicht immer) ja einfach alle Daten ausliest, und nicht nach bestimmten suchen muss.

Und noch was: Kann man Indexe auch nachträglich hinzufügen? also wenn man merkt, dass die Tabelle zu groß wird und die Queries zu langsam?

3. Muss man diese Index-Tabellen ab und zu aktualisieren, oder passiert das automatisch? Ich glaube, ich habe gelesen, dass es nicht automatisch geht und man deshalb solche Indexe hauptsächlich bei Tabellen verwenden sollte, in denen man nicht ständig was einträgt, sondern nur SELECTed.

Danke schon mal :D
 
d3mueller hat gesagt.:
Code: 
CREATE INDEX researchNamesIndexes
ON researchNames (researchName)

Dann würde er doch Indexe für die Namens-Spalte dieser Tabelle erstellen. Muss ich dann, wenn ich Daten auslesen will, diese neu erstellte Index-Tabelle nehmen, oder ganz normal
Code: 
SELECT * FROM researchNames
Zum Vergrößern anklicken....
Ja, so erstellst du einen Index. Aber nur einen und nicht mehrere wie du schreibst. Nein, du selektierst ganz normal. Der Optimizer des DBMS wir dann entscheiden, ob er den Index verwenden will oder nicht. In deinem Beispiel wo du alles selektierst, wir er sich dafür entscheiden den Index nicht zu verwenden. Denn er muss ja sowieso einen full table scan machen. Wenn du aber sagen würdest SELECT researchID FROM researchNames WHERE researchName='HauMichTot'; dann wir er den Index verwenden wollen.


d3mueller hat gesagt.:
Und noch was: Kann man Indexe auch nachträglich hinzufügen? also wenn man merkt, dass die Tabelle zu groß wird und die Queries zu langsam?
Zum Vergrößern anklicken....
Ja, das kann man und so macht man das normalerweise auch. PK, FK sind da die Ausnahme, da man hier schon im voraus sagen kann, dass man diese Spalten tendenziell oft verwenden wird. Ein PK constraint z.B. ist einem Unique Index sehr nahe. Der Unterschied ist nur, dass PK's immer not null sein müssen und du davon pro Tabelle nur einen haben kannst.

d3mueller hat gesagt.:
3. Muss man diese Index-Tabellen ab und zu aktualisieren, oder passiert das automatisch? Ich glaube, ich habe gelesen, dass es nicht automatisch geht und man deshalb solche Indexe hauptsächlich bei Tabellen verwenden sollte, in denen man nicht ständig was einträgt, sondern nur SELECTed.
Zum Vergrößern anklicken....
Falsch. Das DBMS sorgt automatisch dafür dass der Index aktuell ist. Dh. jedes mal wenn du ein Insert/Update/Delete auf eine Indexierte Tabelle machst, sorgt das DBMS im Hintergrund dafür, dass auch der Index angepasst wird. Sprich: ein Index ist nicht gratis! Er macht solche Operationen langsamer, dafür im Gegenzug ein Select viel schneller.

Beim Indexieren muss man immer abwägen. Wie werden die Daten abgefragt? Was sind häufige Queries? Wenn eine Query einige Minuten dauert, aber nur einmal pro Monat verwendet wird, macht es wohl wenig Sinn dafür einen Index bereitzustellen. Hingegen wenn eine Query 30 Sekunden dauert aber 1000 mal am Tag gebraucht wird, ist die Sache schon ganz anders.


PS: welches DBMS hast du denn? Unterschiedliche DBs haben unterschiedliche Indizes zur Auswahl.

Sehr gute Website über Indizes:
http://use-the-index-luke.com/de/sql/inhaltsverzeichnis
 
Okay, dann muss ich mal schauen, wo ich Indexe anlege. Danke :)

Ich benutze MySQL.

Die Webseite ist ja richtig gut :D Die werde ich mir mal durchlesen
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück