nicht angemeldet
Geschwindigkeit, zwei SELECT Befehle verschachtelt?
0 0 0 0 0
Geschwindigkeit, zwei SELECT Befehle verschachtelt?
Ich habe zwei MYSQL Tabellen in der ersten (Tabelle1) sind die verschiedenen Titel hinterlegt.
In der zweiten (Tabelle2) sind die Bilder die in im Feld pictures der Tabelle1, Feld ID zugeordnet sind.
So kann ich z.B. alle Titel mit der ID 1 aus der Tabelle1 in Tabelle2 pictures abfragen.
Ich möchte nun einfach alle meine Titel ausgeben und dahinter die betreffenden Anzahl der jeweiligen Bilder angeben.
Das mache ich mit:
SELECT a.id, a.titel,
(SELECT COUNT(*) FROM tabelle2 b WHERE b.pictures = a.id) anzahl
FROM tabelle1 a
Es funktioniert auch einbandfrei, doch ich finde Geschwindigkeit lässt hierbei sehr zu wünschen übrig. Gibt es eine bessere Möglichkeit die Anzahl der Bilder aus der zweiten Tabelle zu ermitteln, außer mit meinem integrierten SELECT Befehl?
Ali
-
SELECT a.id, a.titel, COUNT(*) FROM tabelle1 a INNER JOIN tabelle2 b ON a.id=b.pictures GROUP BY a.id, a.titel
Bitte nachschauen was das einzelne tut :-)-
moin,
SELECT a.id, a.titel, COUNT(*) FROM tabelle1 a INNER JOIN tabelle2 b ON a.id=b.pictures GROUP BY a.id, a.titel
Bitte nachschauen was das einzelne tut :-)in dem falle unnötige schritte, ich joine erst und verdichte die daten dann wieder mit GROUP BY, das kostet nur unnötig. viel wichtiger wäre erst mal zu klären, ob in der tabelle2 auf der spalte pictures ein index liegt.
Ilja
-
in dem falle unnötige schritte, ich joine erst und verdichte die daten dann wieder mit GROUP BY, das kostet nur unnötig.
Kommt drauf an wie die Indexe liegen, wie viele Einträge die Tabellen an sich etwa haben und wie viele Eingträge davon anhand welcher Indexe ausgewählt werden.
pictures klingt aufgrund des Vergleichs mit a.id schon nach Identität, da sollte natürlich ein Index drauf liegen. Ich nehm sogar an ein primary key.
Die DB sollte dann schon auch ein bisschen mitdenken, wie sie die Abfrage ausführt.
Wie würdest du es sonst machen?-
moin
in dem falle unnötige schritte, ich joine erst und verdichte die daten dann wieder mit GROUP BY, das kostet nur unnötig.
Kommt drauf an wie die Indexe liegen, wie viele Einträge die Tabellen an sich etwa haben und wie viele Eingträge davon anhand welcher Indexe ausgewählt werden.probieren geht über studieren, aber in dem falle würde ich sagen das GROUP macht keinen sinn, es ist einfach mehr arbeit für das DBMS ohne mehrgewinn. du hast mit dem GROUP BY definitiv eine sortierung drinne, die es nicht braucht.
pictures klingt aufgrund des Vergleichs mit a.id schon nach Identität, da sollte natürlich ein Index drauf liegen. Ich nehm sogar an ein primary key.
Die DB sollte dann schon auch ein bisschen mitdenken, wie sie die Abfrage ausführt.auch das ist meiner meinung nach nicht relevant, er muss eh einen full join auf tabelle1 machen. ich würde die abfrage so machen, wie er es geschrieben hat, ich vermute es fehlt der index auf dem foreign key und gut ist.
Ilja
-
Aber gerade das was er macht (pro Ergebnis aus A eine separate Suche in B) macht die Sache ja so langsam. Ich weiß zwar nicht genau wie die Datenbank da optimiert, aber wenn sie alles auf einmal macht, sollte sie schon schneller sein.
Ich würds wie du sagst einfach ausprobieren.
Und Indexe checken, ganz wichtig!-
Aber gerade das was er macht (pro Ergebnis aus A eine separate Suche in B) macht die Sache ja so langsam.
das musst du beim join auch tun, den passenden join partner finden. nur du musst noch zusätzlich sortieren. was es langsam macht, das wird der fehlende index sein, nicht die korrelierte unterabfrage
Ilja
-
Wieviele INDEXE kann mann den machen? Ich frage nur, wenn man die eine Spalte für etwas braucht und eine weitere füer eine andere Abfrage?
Sam
Aber gerade das was er macht (pro Ergebnis aus A eine separate Suche in B) macht die Sache ja so langsam.
das musst du beim join auch tun, den passenden join partner finden. nur du musst noch zusätzlich sortieren. was es langsam macht, das wird der fehlende index sein, nicht die korrelierte unterabfrage
Ilja
-
Wieviele INDEXE kann mann den machen? Ich frage nur, wenn man die eine Spalte für etwas braucht und eine weitere füer eine andere Abfrage?
grundsätzlich musst du dir darüber keine sorgen machen,ob es da ein festes limit gibt, aber trotzdem sollte man indexe mit bedacht einsetzen. sie beschnleunigen zwar die datensuche, aber verlangsamen das einfügen oder ändern der daten, da die indexe mit aktualisiert werden.
Ilja
-
-
Hi,
das musst du beim join auch tun, den passenden join partner finden. nur du musst noch zusätzlich sortieren.
das Sortieren kann man bei MySQL explizit mittels "ORDER BY NULL" unterdrücken, siehe ORDER BY Optimization
Gruß,
Andreas.-
moin,
das Sortieren kann man bei MySQL explizit mittels "ORDER BY NULL" unterdrücken, siehe ORDER BY Optimization
erstens beziehe ich mich auf GROUP BY klausel und zweitens, warum soll ich etwas veranlassen, um es dann zu unterdrücken, wenn ich es eh nicht brauche ?
Ilja
-
Hi Ilja,
erstens beziehe ich mich auf GROUP BY klausel und zweitens, warum soll ich etwas veranlassen, um es dann zu unterdrücken, wenn ich es eh nicht brauche ?
ich ja auch - bei Angabe von GROUP BY automatisch auch sortiert, hast du ja in diesem Beitrag auch geschrieben (was man bei MySQL eben mittels ORDER BY NULL unterdrücken kann). Ich dachte, darauf zielte deine Anmerkung. Da habe ich mich aber scheinbar vertan, nichts für ungut :)
Gruß,
Andreas.
-
-
-
-
-
-
-
-