phpbar.de logo

Mailinglisten-Archive

Performance-Problem

Performance-Problem

Michael Bergbauer mysql-de_(at)_lists.bttr.org
Sun, 10 Feb 2002 19:58:49 +0100 (CET)


On 10-Feb-2002 Marc Albrecht wrote:
> Moin,
> 
>> > 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?
> 
> Nein, in der betreffenden Tabelle wird _meist_ geINSERTed (aber immer mit
> neuen Primary IDs, wobei, wenn mySQL das ignoriert, das wohl weniger wichtig
> ist), ab und zu jedoch "am Block" auch deleted. geUPDATEd wird recht selten
> (bis nie).

Also grundsätzlich, so wie ich es bisher in der Praxis beobachtet hab:
Wenn du neue DS einfügst, werden diese "hinten" angefügt. Löscht du Datensätze
raus, bleiben die in den MyISAM-Blöcken vorerst mal ungenutzt, und bei Bedarf
und Möglichkeit bei neuen Inserts recycelt. Wenn du also immer wieder löscht
und neu einfügst, dann sind deine Datensätze nicht mehr nach dem Primary Key
sortiert (wenn's dieser beim Befüllen ist)

>> 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.
> 
> Woops. Das haut ja in die gleiche Kerbe - und dürfte, wenn es sich als ein
> _generelles_ Problem herausstellt, für unsere weiteren Projekte das absolute
> KO-Kriterium für mySQL sein... das möchte ich nicht hoffen, denn ich fühle
> mich mittlerweile sehr wohl mit dieser Lösung.

Ich hoffe, du hast nen guten MySQL-Support-Vertrag und kannst den Kerlen mal
direkt "auf die Finger klopfen". Für mich ist es nicht so wichtig, die
Antwortzeiten sind bei mir immer noch im Bereich unter 0.5 Sekunden, und ich
hab 
a) kaum User, die diese Tabellen beanspruchen 
b) eine Single-Thread-Anwendung drum rum 
c) die zudem noch auf ner VM läuft (nein, nicht Java)
d) ich limit nicht benutze.

BTW: Kannst du mir mal privat die Ursprungsmail nochmal zukommen lassen? Ich
muss zugeben, ich hab sie nicht gelesen. Wenn ich schon was teste, dann unter
gleichen Bedingungen wie du, nicht um hier jemanden zu unrecht in Bedrängnis zu
bringen. 


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 



php::bar PHP Wiki   -   Listenarchive