Performance-Problem

[Michael Bergbauer]

On 10-Feb-2002 Marc Albrecht wrote:
> Moin,
> 
>> So eine pauschale Aussage halte ich mal für falsch, und zwar auf folgenden
>> Gründen:
>> 1. Könnten alle deine Felder in einem Index liegen, idealerweise dem, der
>> zur
>> where-Bedinung herangezogen wird. Dann reicht es IMHO, den Index zu lesen,
>> und
>> nicht auch noch die Tabelle
>> 2. Könntest du ein BLOB Feld in der DB haben mit einigen hundert KB Daten
>> pro
>> Zeile. Es geht auf jeden Fall schneller, nur die 5 oder 6 Spalten zu lesen,
>> ohne das BLOB.
>> 3. Musst du im Falle von SELECT * (wesentlich) mehr Speicher lokal kopieren,
>> bzw. die Daten auch über das Netzwerk verschicken.
>> 
>> Alles Gründe, die deine Aussage ein wenig zweifelhaft erscheinen lassen.
> 
> Das hat mit meiner ursprünglichen Frage nur noch wenig zu tun:

Drum hab ich deine Frage ja auch komplett weggekürzt, und nur diese pauschale
Aussage stehen gelassen, auf die ich mich bezogen haben. 
 
> Nochmal - die ersten paar tausend Datensätze werden schnell gelesen. 
> Dann bricht die Geschwindigkeit immer mehr zusammen. Das deutet für mich 
> auf ein grundlegendes Problem im Zusammenhang mit Lesen von den 
> Festplatten hin - nicht auf ein Probem des Selects.
> 
> Wir BRAUCHEN im Select _alle_ Daten aus der Tabelle, nicht nur einen 
> Index - der interessiert uns überhaupt nicht. Wir müssten mithin einen 
> zweiten, dritten bis x-ten Select auf die Daten absetzen, wenn wir in 
> jedem Zugriff nur einzelne Elemente lesen wollten. Das halte ich vom 
> Ansatz her für wenig sinnvoll.
> 
> Und nochmal dieses: wir LIMITIEREN den Zugriff. Wir holen nur die Zeilen 
> aus der Tabelle, die wir (KOMPLETT) haben wollen. Auch das stand in 
> meiner Ursprungsmail (select * from tabelle limit .....)
> 
> Meine Frage bezieht sich - das versuche ich gerne noch einmal darzulegen 
> - darauf, wie wir bei einer 360MB-großen MYD-Datei auch die Datensätze, 
> die in der Tabelle (primary key!) weiter "hinten" liegen, in adäquater 
> Geschwindigkeit erhalten können. 

MYSQL sortiert nicht nach dem Primary Key. Ich hab leider deine Frage nicht
hier, aber ich denk mal die Frage, die ich hab wird da nicht drin stehen. Wird
in dieser Tabelle oft gelöscht und neu eingefügt, kann es also sein, das viele
Lücken in den MyISAM Blöcken stehen und diese wieder durch neuere Datensätze,
die eigentlich "hinten" stehen müssen gefüllt werden?

Hast du schon mal einen optimize Table gemacht und dann die Performance
getestet?

> Eine Lösung - auch DAS schrieb ich 
> schon! - wäre ja, die Tabelle zu splitten. Dann könnten wir aber gleich 
> alle Daten in Files packen und auf eine Datenbank verzichten. Die 
> GLEICHE Datenbank unter Oracle läuft zwar generell deutlich langsamer, 
> bleibt aber auch bei Zugriffen auf die "hinteren" Zeilen nahezu gleich 
> performant. Es dünkt mich mithin, ein typisches mySQL-Problem zu sein.

Ich hab mal kurze Tests gemacht, in einer Tabelle mit ca. 200k Einträgen. Je
nachdem, wo ich die Datensätze rausnehme, schwankt die Zeit um ca. Faktor 50.
Also im allgemeinen kann ich dein Problem bestätigen (und nein, AFAIK wurde
_diese_ Tabelle nur einmal gefüllt, und verrichtet seitdem ihren Dienst.

Scheint so, als würde MySQL in dem Bereich schlecht skalieren, ich weiss
allerdings nicht, wie es mit neueren Versionen ist (3.23.30)

> Für HILFE wäre ich sehr dankbar. Ich geben gerne jede Art von 
> Information heraus, die hierbei helfen kann. Ideologische Diskussionen 
> bringen mich aber (leider) nicht weiter.

Dann verbreit keinen ideologischen Schwachsinn, dann muss den keiner
korregieren.

Im übrigen gibts keinen Grund, in der Gegend rumzuschreien.

Michael

-- 
michael Bergbauer <michael_(at)_noname.franken.de>
Use your idle CPU cycles.
See http://www.distributed.net and win $ 1 000.
Visit our mud Geas at geas.franken.de Port 3333

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