Ich war neugierig. Und wie wir alle wissen, hat Neugier den Ruf, Katzen zu töten.
Also, was ist der schnellste Weg, eine Katze zu häuten?
Die genaue Umgebung für das Häuten von Katzen für diesen Test:
- PostgreSQL 9.0 auf Debian Squeeze mit anständigem RAM und Einstellungen.
- 6.000 Studenten, 24.000 Clubmitgliedschaften (Daten aus einer ähnlichen Datenbank mit realen Daten kopiert.)
- Leichte Ablenkung vom Namensschema in der Frage:
student.id
ist student.stud_id
und club.id
ist club.club_id
hier.
- Ich habe die Abfragen in diesem Thread nach ihrem Autor benannt, mit einem Index, in dem es zwei gibt.
- Ich habe alle Abfragen ein paar Mal ausgeführt, um den Cache zu füllen, und dann mit EXPLAIN ANALYZE das Beste aus 5 ausgewählt.
Relevante Indizes (sollten das Optimum sein - solange wir nicht wissen, welche Clubs abgefragt werden):
ALTER TABLE student ADD CONSTRAINT student_pkey PRIMARY KEY(stud_id );
ALTER TABLE student_club ADD CONSTRAINT sc_pkey PRIMARY KEY(stud_id, club_id);
ALTER TABLE club ADD CONSTRAINT club_pkey PRIMARY KEY(club_id );
CREATE INDEX sc_club_id_idx ON student_club (club_id);
club_pkey
wird von den meisten Abfragen hier nicht benötigt.
Primärschlüssel implementieren eindeutige Indizes automatisch in PostgreSQL.
Der letzte Index soll diesen bekannten Mangel an mehrspaltigen Indizes unter PostgreSQL ausgleichen:
Ein mehrspaltiger B-Baum-Index kann mit Abfragebedingungen verwendet werden, die eine beliebige Teilmenge der Indexspalten betreffen. Der Index ist jedoch am effizientesten, wenn Einschränkungen für die führenden Spalten (ganz links) bestehen.
Ergebnisse:
Gesamtlaufzeiten von EXPLAIN ANALYZE.
1) Martin 2: 44,594 ms
SELECT s.stud_id, s.name
FROM student s
JOIN student_club sc USING (stud_id)
WHERE sc.club_id IN (30, 50)
GROUP BY 1,2
HAVING COUNT(*) > 1;
2) Erwin 1: 33,217 ms
SELECT s.stud_id, s.name
FROM student s
JOIN (
SELECT stud_id
FROM student_club
WHERE club_id IN (30, 50)
GROUP BY 1
HAVING COUNT(*) > 1
) sc USING (stud_id);
3) Martin 1: 31,735 ms
SELECT s.stud_id, s.name
FROM student s
WHERE student_id IN (
SELECT student_id
FROM student_club
WHERE club_id = 30
INTERSECT
SELECT stud_id
FROM student_club
WHERE club_id = 50);
4) Derek: 2,287 ms
SELECT s.stud_id, s.name
FROM student s
WHERE s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 30)
AND s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 50);
5) Erwin 2: 2,181 ms
SELECT s.stud_id, s.name
FROM student s
WHERE EXISTS (SELECT * FROM student_club
WHERE stud_id = s.stud_id AND club_id = 30)
AND EXISTS (SELECT * FROM student_club
WHERE stud_id = s.stud_id AND club_id = 50);
6) Sean: 2,043 ms
SELECT s.stud_id, s.name
FROM student s
JOIN student_club x ON s.stud_id = x.stud_id
JOIN student_club y ON s.stud_id = y.stud_id
WHERE x.club_id = 30
AND y.club_id = 50;
Die letzten drei sind ziemlich gleich. 4) und 5) führen zu demselben Abfrageplan.
Späte Ergänzungen:
Ausgefallene SQL, aber die Leistung kann nicht mithalten.
7) Ypercube 1: 148,649 ms
SELECT s.stud_id, s.name
FROM student AS s
WHERE NOT EXISTS (
SELECT *
FROM club AS c
WHERE c.club_id IN (30, 50)
AND NOT EXISTS (
SELECT *
FROM student_club AS sc
WHERE sc.stud_id = s.stud_id
AND sc.club_id = c.club_id
)
);
8) Ypercube 2: 147,497 ms
SELECT s.stud_id, s.name
FROM student AS s
WHERE NOT EXISTS (
SELECT *
FROM (
SELECT 30 AS club_id
UNION ALL
SELECT 50
) AS c
WHERE NOT EXISTS (
SELECT *
FROM student_club AS sc
WHERE sc.stud_id = s.stud_id
AND sc.club_id = c.club_id
)
);
Wie erwartet arbeiten diese beiden fast gleich. Der Abfrageplan führt zu Tabellenscans. Der Planer findet hier keine Möglichkeit, die Indizes zu verwenden.
9) Wildplasser 1: 49,849 ms
WITH RECURSIVE two AS (
SELECT 1::int AS level
, stud_id
FROM student_club sc1
WHERE sc1.club_id = 30
UNION
SELECT two.level + 1 AS level
, sc2.stud_id
FROM student_club sc2
JOIN two USING (stud_id)
WHERE sc2.club_id = 50
AND two.level = 1
)
SELECT s.stud_id, s.student
FROM student s
JOIN two USING (studid)
WHERE two.level > 1;
Ausgefallene SQL, anständige Leistung für einen CTE. Sehr exotischer Abfrageplan.
Auch hier wäre interessant, wie 9.1 damit umgeht. Ich werde den hier verwendeten Datenbankcluster bald auf 9.1 aktualisieren. Vielleicht werde ich den ganzen Schebang wiederholen ...
10) Wildplasser 2: 36,986 ms
WITH sc AS (
SELECT stud_id
FROM student_club
WHERE club_id IN (30,50)
GROUP BY stud_id
HAVING COUNT(*) > 1
)
SELECT s.*
FROM student s
JOIN sc USING (stud_id);
CTE-Variante von Abfrage 2). Überraschenderweise kann dies zu einem etwas anderen Abfrageplan mit genau denselben Daten führen. Ich fand einen sequentiellen Scan an student
, bei dem die Unterabfrage-Variante den Index verwendete.
11) Ypercube 3: 101,482 ms
Ein weiterer später Zusatz @ypercube. Es ist wirklich erstaunlich, wie viele Möglichkeiten es gibt.
SELECT s.stud_id, s.student
FROM student s
JOIN student_club sc USING (stud_id)
WHERE sc.club_id = 10 -- member in 1st club ...
AND NOT EXISTS (
SELECT *
FROM (SELECT 14 AS club_id) AS c -- can't be excluded for missing the 2nd
WHERE NOT EXISTS (
SELECT *
FROM student_club AS d
WHERE d.stud_id = sc.stud_id
AND d.club_id = c.club_id
)
)
12) Erwin 3: 2,377 ms
@ ypercubes 11) ist eigentlich nur der umwerfende umgekehrte Ansatz dieser einfacheren Variante, der auch noch fehlte. Leistung fast so schnell wie die Top-Katzen.
SELECT s.*
FROM student s
JOIN student_club x USING (stud_id)
WHERE sc.club_id = 10 -- member in 1st club ...
AND EXISTS ( -- ... and membership in 2nd exists
SELECT *
FROM student_club AS y
WHERE y.stud_id = s.stud_id
AND y.club_id = 14
)
13) Erwin 4: 2,375 ms
Kaum zu glauben, aber hier ist eine andere, wirklich neue Variante. Ich sehe Potenzial für mehr als zwei Mitgliedschaften, aber es zählt auch zu den Top-Katzen mit nur zwei.
SELECT s.*
FROM student AS s
WHERE EXISTS (
SELECT *
FROM student_club AS x
JOIN student_club AS y USING (stud_id)
WHERE x.stud_id = s.stud_id
AND x.club_id = 14
AND y.club_id = 10
)
Dynamische Anzahl von Clubmitgliedschaften
Mit anderen Worten: unterschiedliche Anzahl von Filtern. Diese Frage stellte genau zwei Clubmitgliedschaften. Viele Anwendungsfälle müssen sich jedoch auf eine unterschiedliche Anzahl vorbereiten.
Detaillierte Diskussion in dieser verwandten späteren Antwort:
(student_id, club_id)
(oder dem umgekehrten) Index versuchen .quelle
quelle
Wenn Sie nur student_id wollen, dann:
Wenn Sie auch einen Namen vom Schüler benötigen, dann:
Wenn Sie mehr als zwei Clubs in einer club_selection-Tabelle haben, dann:
quelle
Oder eine allgemeinere Lösung, die sich leichter auf
n
Clubs ausweiten lässt und die vermeidetINTERSECT
(in MySQL nicht verfügbar) undIN
(da die Leistung in MySQL schlecht ist )quelle
HAVING
in MySQL funktioniert.Ein weiterer CTE. Es sieht sauber aus, generiert aber wahrscheinlich den gleichen Plan wie ein Groupby in einer normalen Unterabfrage.
Für diejenigen, die testen möchten, eine Kopie meines generierten Testdaten-Dings:
quelle
Es gibt also mehr als einen Weg, eine Katze zu häuten .
Ich werde zwei weitere hinzufügen , um es vollständiger zu machen.
1) GRUPPE zuerst, später beitreten
Angenommen, ein vernünftiges Datenmodell
(student_id, club_id)
ist einzigartig instudent_club
. Martin Smiths zweite Version ist ähnlich, aber er schließt sich zuerst Gruppen später an. Das sollte schneller gehen:2) EXISTIERT
Und natürlich gibt es den Klassiker
EXISTS
. Ähnlich wie Dereks Variante mitIN
. Einfach und schnell. (In MySQL sollte dies etwas schneller sein als die Variante mitIN
):quelle
Da niemand diese (klassische) Version hinzugefügt hat:
o.ä:
Noch ein Versuch mit einem etwas anderen Ansatz. Inspiriert von einem Artikel in Explain Extended: Mehrere Attribute in einer EAV-Tabelle: GROUP BY vs. NOT EXISTS :
Ein anderer Ansatz:
quelle
(stud_id, club_id)
und(club_id, stud_id)
(oder Primary und Unique) zu haben? Ich denke immer noch, dass für einige dieser Abfragen der Unterschied zwischen 2 und 140 ms zu hoch ist, um durch die Unterschiede in den Ausführungsplänen erklärt zu werden.Dies scheint recht gut zu funktionieren, da beim CTE-Scan keine zwei separaten Unterabfragen erforderlich sind.
Es gibt immer einen Grund, rekursive Abfragen zu missbrauchen!
(Übrigens: MySQL scheint keine rekursiven Abfragen zu haben.)
quelle
Unterschiedliche Abfragepläne in Abfrage 2) und 10)
Ich habe in einer realen Datenbank getestet, daher unterscheiden sich die Namen von der Katzenhautliste. Da es sich um eine Sicherungskopie handelt, hat sich während aller Testläufe nichts geändert (mit Ausnahme geringfügiger Änderungen an den Katalogen).
Abfrage 2)
Abfrage 10)
quelle
@ erwin-brandstetter Bitte Benchmarking:
Es ist wie Nummer 6) von @sean, nur sauberer, denke ich.
quelle
@
Benachrichtigen nur in Kommentaren funktioniert, nicht in Antworten. Ich bin zufällig auf diesen Beitrag gestoßen. Der Abfrageplan und die Leistung Ihrer Abfrage sind identisch mit Seans Abfrage. Es ist praktisch dasselbe, aber Seans Abfrage mit expliziterJOIN
Syntax ist die allgemein bevorzugte Form, weil sie klarer ist. +1 für eine weitere gültige Antwort!Der Abfrageplan:
Es scheint also immer noch den seq-Scan des Schülers zu wollen.
quelle
Verwendung der schnellsten Variante (Mr. Sean in Mr. Brandstetter-Tabelle). Kann eine Variante mit nur einem Join sein, nur die student_club-Matrix hat das Recht zu leben. Die längste Abfrage muss also nur mit zwei Spalten berechnet werden. Die Abfrage sollte daher dünn sein.
quelle