Performante SQLs

[Schiller Stefan]

Hallo,

ich programmiere gerade ein kleines Geschichtenarchiv mit PHP/MYSQL, und habe ein paar Performancefragen.

Datenbank (vereinfacht):

• Benutzer (UID, Namen, …)
• Benutzermailadressen (UID, Mailadresse)
• Geschichten (SID, UID, Title)
• Kapitel (SID, CHID, Title)
• Kommentare (SID, UID, Kommentar)

1. Ich möchte eine Liste aller Benutzer und deren Mailadressen haben.

SELECT * FROM Benutzer b, Bernutzermailadressen a WHERE b.uid = a.uid ORDER BY …
ODER sollte ich die beiden Tabellen joinen?

2. Ich möchte eine Statistik programmieren, die Anzeigt, welche Geschichte wie viele Kapitel und wie viele Kommentare hat.

Ich habe das derzeit so in einem SQL gelöst:
SELECT (SELECT count(ka.*) FROM Kapitel ka WHERE ka.sid = g.sid) as cnt1, (SELECT count(ko.*) FROM Kommentare ko WHERE ko.sid = g.sid) as cnt2 FROM Geschichten g ORDER BY …

Ich könnte mir aber auch vorstellen ZUERST alle Geschichten herauszuholen und dann 2 einzelne SQLs pro Geschichte zu machen, wo ich aber hörte, dass man lieber einen großen, statt viele kleine machen sollte.

Ich hoffe, ihr könnt mir da helfen.

LG Stefan.

[dedlfix]

Hi!

ich programmiere gerade ein kleines Geschichtenarchiv mit PHP/MYSQL, und habe ein paar Performancefragen.

Grundlegendes Prinzip: Miss die Ausführungszeit all deiner Ideen und vegleiche sie. Es gibt so viele mögliche Fälle, dass theoretische Überlegungen zur Performance nicht immer stimmen müssen. Deswegen ist es nicht günstig, sich für andere Anwendungen blind auf einmalig erarbeitete Vergleiche zu stützen. EXPLAIN hilft (nach Einarbeitung) auch, die Schwachstellen zu erkennen. In der Regel bringen auf die Abfragen zugeschnittene Indexe die größten Performancevorteile. Sie können aber auch bremsen, wenn viele Daten zu ändern sind und der Index zusätzlich immer wieder neu gebaut werden muss.

Zu Performance-Überlegungen ist auch die Anzahl der Daten interessant. Bei zu wenigen Datensätzen ist die Performance vernachlässigbar, weil alle Abfragevarianten im Grundrauschen untergehen. Auch kann es sein, dass das DBMS erst ab einer gewissen Anzahl oder Kardinalität von Datensätzen zu Optimierungen greift, so dass Messergebnisse nicht einfach hochgerechnet werden können.

1. Ich möchte eine Liste aller Benutzer und deren Mailadressen haben.
   SELECT * FROM Benutzer b, Bernutzermailadressen a WHERE b.uid = a.uid ORDER BY …
   ODER sollte ich die beiden Tabellen joinen?

Ist schon gejoint. Das ist die implizite Schreibweise für einen Inner Join. Wenn dir die noch niht bekannt sind, recherchiere die Auswirkungen auf das Ergebnis (nicht die Performance) im Gegensatz zu einem Left Join.

Ich könnte mir aber auch vorstellen ZUERST alle Geschichten herauszuholen und dann 2 einzelne SQLs pro Geschichte zu machen, wo ich aber hörte, dass man lieber einen großen, statt viele kleine machen sollte.

Viele kleine bedeuten viele Roundtrips zum DBMS nebst dem Overhead für das Handling der SQL-Statements. Messen schafft konkrete Klarheit (und erweitert den persönlichen Erfahrungsschatz).

Lo!