[php] Ausführungszeit von MySQL-Abfragen

[Hans Egg]

Hallo Andreas

Danke für die interessanten Gedanken und Hinweise.

Am 23.12.2010 um 19:23 schrieb Andreas Kempf:

> Wie an anderer Stelle geschrieben, hattest du das "LIMIT 30"  
> vergessen.
> Ich wundere mich, dass es so einen eklatanten Unterschied macht. Denn
> das "ORDER BY real_name" erfordert ja, dass erstmal alle 10.000
> Records/Tupels gefunden werden müssen, von denen dann aber nur 30
> dargestellt werden sollen.

MySQL ist so schlau ist, die Subselect erst nach dem LIMIT  
auszuführen, wenn sie nicht im ORDER BY benutzt werden! Wenn ich nach  
Attributen sortiere, deren Werte ich per Subselect zusammenklaube,  
wird das Ganze massiv langsamer und praktisch unabhängig vom LIMIT.

Wir haben inzwischen die komplizierten Subselect-Berechnungen in den  
Schreibzyklus verlagert, d.h. wir aktualisieren beim Schreiben der  
Daten zusätzliche Dimensionstabellen mit fertig berechneten Werten für  
den Lesezugriff. Ähnlich wie das im Sternschema eines Data-Warehouses  
üblich ist.

Die Schreibvorgänge erfolgen über den ganzen Tag verteilt durch die  
Kunden und sind völlig unkritisch bezüglich Zeitverhalten. Die  
Lesevorgänge kommen zu Hauf auch von einem einzelnen Besucher. Wenn  
der nur ein bisschen an der Google-Map schraubt oder in die Tagcloud  
klickt, löst das wieder einen Request an die API und die DB aus. Mit  
der getroffenen Lösung sind wir bezüglich Datendurchsatz über die API  
rund 50 x schneller. Inzwischen ist die Google-Map der Flaschenhals  
und der "Schwarze Peter" ist wieder beim Frontend Developer ;-)

Es handelt sich übrigens im um die Schnittstelle zwischen Frontend und  
Backend bei www.lunchgate.com

Frohe Weihnachten allerseits!

Gruß, Hans