Das ist voll in die Hose gegangen, aus Gründen* ist das ganze Biest noch lahmer.
Simpelste select counts die den DB-Server (und damit die dranhängende Applikation) für 10 Minuten blockieren können sind krass, und ich habe keine Ahnung wie das zu lösen sein könnte – aus einem, ähm, suboptimalen DB-Schema läßt sich wohl nicht mehr viel rausholen, außer möglicherweise eine _richtig_ große Serverkiste hinzustellen.
Ich dreh noch durch hier, *genau* so habe ich mir den Wochenanfang vorgestellt.
*) es müssen gute Gründe sein – schließlich verstehe ich sie nicht
6 Antworten auf „zu wenig Daumen“
Und doch sollte ein Count nicht vom DB Schema abhängen…DB-Performance ist extrem von den indices, aktuellen Statistiken sowie so-optimistisch-wie-möglich-Locking abhängig. Da kannst Du Prozessoren draufwerfen wie Du willst…
Ich glaube, ich muss dir mal eine Gilfe geben: Bei deiner MySQL-Datenbank würde ich mal mit dem Tuning-Primer nachschauen, wo es klemmt, evtl. musst du nur die Konfiguration ein wenig „optimieren“.
Vergleiche hierzu einfach mal meinen Beitrag unter http://blog.huebel-online.de/2007/11/07/warum-sind-social-networks-manchmal-so-langsam/
Helfen kann ich da aus der Ferne leider nicht, nur dem Frank zustimmen (und Kim?): Das klingt nach einem Problem, dass man nicht durch mehr Performance lösen kann.
Aus meinem Studium bzw. dem Datenbankpraktikum weiß ich noch: Es hängt auch stark von der Formulierung der SQL-Query ab. Während die Musterlösung 30 Minuten gebraucht hat, lief meine Lösung korrekt in 30 Sekunden (kein Witz).
Frank: Indices war schon mal nicht schlecht
Kim: verwende ich schon länger, aber danke
Nielsson: Jupp, so was war es, OR in Queries lassen sich nicht durch Indices beschleunigen
Gute Nacht allerseits :)
Das klingt als hättest du zumindest irgendwas gefunden?
die beiden Hauptperformancerkiller sind gefixt, die restlichen Queries werden so nach und nach umgebaut. Mal sehen