phpbar.de logo

Mailinglisten-Archive

Performance-Problem

Performance-Problem

Michael Donning mysql-de_(at)_lists.bttr.org
Wed, 13 Feb 2002 09:28:36 +0100


Hallo Marc,

> -----Original Message-----
> From: Marc Albrecht [mailto:albrecht_(at)_act-net.com]
> hmmm... wie ich ja schrieb, zeigt die Status-Anzeige "sending data",
> nicht aber "sorting" (das Sorting geht innerhalb von ein, zwei Sekunden
> vonstatten). Dies deutet mir weniger auf ein Optimierungsproblem beim
> unsortierten Zugriff hin - oder?

Ähhm Dein Zugriff Select * from table ist unsortiert, da die Sätze
(zumindest theoretisch) so in beliebiger Reihenfolge ankommen. Ohne jetzt
darauf abzufahren, mit unsortiert meine ich einen Zugriff ohne Schlüssel (a
la table scan) und natürlich ohne ORDER BY, bei unsortiert findet natürlich
auch kein "sorting" statt.

> Zu beiden Vorschlägen ist zu sagen, daß das Limit deshalb eingesetzt
> wird, weil von allen möglichen Suchergebnissen immer nur ein paar
> gebraucht werden (es wird in der Applikation nicht _immer_ nach "*"
> gesucht sondern - natürlich - auch nach eingegrenzten Werten). Da es in
> keinster Weise vorhersehbar ist, WELCHE Seiten vom Anwender gebraucht
> werden (sprich: welche Zeilen per Limit abgefragt werden müssen), deucht
> mich ein "use_result" die Sache nur im Test-Bereich zu beschleunigen.

Bei use_result wird das Abfrageergebnis nicht erst im Speicher
zwischengelagert bis komplett, sondern "sofort" an den client geschickt.
Dafür lockt es aber die Tabelle solange bis der client mit der Abfrage
fertig ist.
Ob das nun sinnvoll ist oder die Besserung bringt kann ich nicht sagen.

> Ja, in dieser Richtung haben wir schon einige Tests gemacht, hat aber
> leider nicht viel gebracht (genau genommen: so gut wie gar nichts - auch
> das Ändern von "text" (ursprünglich verwendet) auf "varchar 32" (als
> Beispiel) hat effektiv 0 gebracht (varchar lässt sich, meines Wissens,
> aber auch auf fixed size einstellen, was zu einer Maximal-Länge führt -
> sollte doch einen ähnlichen Effekt haben, oder?`)

Mit Text gehts glaube ich nicht. Bei fixen Record-größen (mit CHAR) ist die
Länge eines Textfeldes auf 255 Zeichen beschränkt.  Von Varchar mit fixed
size hab ich noch nichts gehört, vielleicht sollte ich mal mein Handbuch
updaten...

Hattes Du nochmal meinen unverbindlichen Hinweis mit dem table_cache
geprüft? (16M scheint mir zu viel, 500 sollte vollkommen reichen, es sei
denn der Parameter hat kurzfristig seine Bedeutung geändert).

Ich persönlich arbeite mit Tabellen die z.T. bis 12Mio Datensätze gehen
(dann aber mit wesentlich kleineren Satzgrößen). Meine Abfragen laufen aber
grundsätzlich über Indizes, daher habe ich Dein Problem noch nicht erlebt.

Gruss Michael Donning

---
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql 



php::bar PHP Wiki   -   Listenarchive