Performance-Problem

[Marc Albrecht]

Moin,

> vielleicht hast Du es ja rausgekriegt, trotzdem glaube ich,
> dass ich mal das selbe Problem hatte.
> Stell Deine query von SELECT * auf weniger ausgewählte
> Felder um (SELECT id, datum) und ermittele damit die Anzahl
> der Datensätze. Bau Dir dann eine Schleife und setze den
> Anfangswert einer Variablen $anfwert auf 0, mach dann eine
> zweite SELECT mit SELECT * FROM ... LIMIT $anfwert, 150


Ähm... wie ich schrieb (siehe unten), MACHE ICH ES SO. 
Selbstverständlich greifen wir per Limit zu.

Ein Select über "*" geht im Übrigen schneller als einer über dedizierte 
Spalten.

Marc Albrecht

> 
> Bei der nächsten query muss natürlich dann der $anfwert um
> 150 hochgesetzt werden.
> 
> Bei mir waren 60000 Datensätze drin und er hat etwa 40000
> problemlos gefunden, dann ist er aber immer gekippt. Mit den
> o.g. Query's habe ich seither keine Probleme mehr. Viel
> Glück.
> 
> Gruss Volker
> 
> Marc Albrecht schrieb:
> 
>>Hallo,
>>
>>wir haben ein Performance-Problem mit mySQL 3.23 - eine Tabelle hat die
>>lächerliche Größe von 360MB (MYD-File), nur 48000 Einträge. Alle
>>Text-Spalten sind indiziert, Zugriffe erfolgen auch nur über die
>>Indizes. Die Datenbank-Files liegen auf einem RAID-0 mit zwei
>>UDMA5-Platten und werden mit DMA angesprochen (unter Linux), Filesystem
>>ist Reiser.
>>
>>Der Zugriff auf die ersten rund 15000 Datensätze erfolgt akzeptabel
>>schnell (Wartezeiten bis zu ca. 8 Sekunden, bis die Daten gepiped sind -
>>egal, ob Zugriff per mysql Commandline Tool oder via PHP). Aber danach
>>geht die Geschwindigkeit derbe den Bach runter: Zugriffe auf die
>>"hinteren" Daten sind nur mit Wartezeiten um die 6-8 Minuten möglichen
>>(SELECT * FROM table LIMIT .....)
>>
>>SHOW_PROCESSLIST zeigt während der Wartezeit den Query-String und
>>"sending data".
>>
>>Ein "cp datafile.MYD /dev/null" läuft in rund 10 Sekunden durch.
>>
>>Hat jemand eine Empfehlung, an welcher Stelle das Problem liegen könnte?
>>Ich bin für jeden Tip dankbar - wir haben schon überlegt, die Table
>>notfalls in Subtables zu unterteilen (wäre dank der Primary Keys
>>möglich), aber SINN einer Datenbank ist ja eigentlich, sowas nicht nötig
>>zu haben :-)
>>
>>Marc Albrecht
>


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