phpbar.de logo

Mailinglisten-Archive

Re: Performance Frage und Indices
Archiv Mailingliste mysql-de

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Performance Frage und Indices



On Sun, Mar 28, 1999 at 03:32:08PM +0200, Matthias Pigulla wrote:
> Norbert Hartl wrote:

> > Die Datenbank laeuft auf einem Dual-PII-233 und einem
> > RAID, das intern mit UW und extern mit Differential
> RAID? Bedenke, daß RAID5 nicht optimal ist für Datenbanken ;-) (Wir
> haben selber Engpässe auf Dual-PII233ern mit RAID5).
> 
Hmmm, nun ja. Angebunden ist das Ding mit Differential, das bei
einem Maximum von 20MB/s liegt RAID5 ist aus meiner Erfahrung
schon optimal, da du ja gezwungen bist, eine Tabelle sonst
auf einer PLatte zu speichern und der Check des RAIDs macht 
sicher nicht den Effekt zunichte, dass ein RAID gleichzeitig
auf alle Platten zugreift und daher von der Performance den
UW-Bus optimal ausnutzt.
Aber ganz sicher bin ich mir eben auch nicht :)

> > Und ich benutze im Moment MySQL 3.22.20a (noch dynamisch
> > gelinkt und mit egcs-1.0.3 kompiliert)
> Wenn es um Performance geht, würde ich die binary distributions
> empfehlen.
> 
Sorry, aber ich mag keine binary distribution. Ich bin der 
Meinung, dass ein System von dem Punkt der Installation von
jedem anderen System abweicht, deshalb ist ein compilieren
auf dem eigenen System AFAIK meist das bessere.
Ich bin auf jeden Fall gerade dabei den pgcc-1.1.1 zu installieren
und werden im Anschluss MySQL als statische Version bauen.
Sollte letztendlich aber Makulatur sein, da mein Performance-
Problem nicht im 20%, sondern im 200% Bereich liegt :(

> > Ich habe hier eine Tabelle, die aus 18 Spalten und einer
> 18 Spalten klingt nach sehr viel für eine gut normalisierte Struktur.
> 
Es geht um Flugtabellen und die Daten kommen von 10 unterschiedlichen
Anbietern. Ich habe schon versucht einen Teil der Dinge aus-
zulagern in eine andere Tabelle, bin damit aber klaeglich
gescheitert. Wenn ich mich nicht zu bloed anstelle, dann geht
es im Moment nicht anders.

> > Es gibt hauptsaechlich 5 Spalten, die in der WHERE-Clause
> > auftauchen koennen. Diese sind kombinierbar, aber es
> > werden 3 davon immer benutzt und eben maximial 5. Ab-
> Ich habe nicht viel Ahnung von Datenbankdesign, aber "drei Spalten, die
> immer benutzt werden" hört sich nach einem Primärschlüssel an. Spricht
> hier etwas gegen die Normalisierungsregeln (mit denen ich mich selber
> nicht so gut auskenne :-)) ?
Ja, es spricht was dagegen. Wenn ich diesen Schluessel aus
den 3 Spalten annehme, dann gilt schon die 1NF nicht mehr,
denn die besagt, dass alle Attribute, die nicht dem Primaer-
schluessel angehoeren, von diesem funktional abhaengig sein
muessen. Und das sind sie nicht. 
Das Bloede an der Tabelle ist, dass letztendlich alle 17 Spalten
ausser der ID der Primaerschluessel sind. Alle Doubletten werfe
ich schon vor dem Einspielen weg.

> > INDEX (col1,col2,col3,col4)
> > INDEX (col1,col2,col3,col5,col4)
> Gibt es einen PRIMARY KEY über (col1,col2,col3)? Gibt es überhaupt einen
> PRIMARY KEY?
Ja, sorry, habe ich nicht deutlich gesagt. Es gibt eine ID
die der Primaerschluessel ist.
> 
> > Darueberhinaus habe ich per explain gesehen, dass oftmals
> > fuer den Fall c.) der erste und nicht der zweite INDEX
> > benutzt wird und das verstehe ich gar nicht.
> Das hängt sehr vom Query ab, ich denke mal, der Optimizer holt schon das
> beste für Dich raus :-)
> 
Aber es sollte doch schneller sein, wenn ein INdex benutzt
wird, der alle gefragten Spalten umfasst oder irre ich mich
da?
Ausserdem geht es mehr um meine Furcht, _nicht_ die richtigen
Indices angelegt zu haben :)

> > 2.) Ich moechte die id als Primary Key von int auf medium-
> > int umstellen. Was passiert, wenn die ID 'ueberlaeuft'?
> > Soweit ich das sehe, hat MySQL keine Moegleichkeit untere
> > leere Bloecke wieder zu verwenden. Da ich jeden Tag ca.
> > 200.000 Datensaetze loesche und einfuege, die nach einem
> > Datumskriterium geloescht werden, bekomme ich einen quasi
> > zusammenhaengen Block von ids, der nach oben wandert.
> Schlimmstenfalls (wenn es möglich ist), die Datenbank sperren. Dann ein
> Update auf alle IDs, die als Schlüssel zusammenhängen, so in etwa SET
> ID=ID-100000 oder so.

D.h. ich muss auf jeden Fall selbst aufpassen, dass es nicht
ueberlaeuft? Hmmm, dann muss ich erstmal testen, wieviel Nutzen
ich davon haette, den Primaerschluessel von int auf mediumint
zu setzen.

Ich habe ausserdem vergessen, dass das Ergebnis nach col4 sortiert
wird, also ORDER BY col4. Gibt es dort noch Regeln, die ich im
Moment nicht beachte, um es klein zu halten?

Danke fuer die Antwort. Komischerweise sind Antwortmails auf
Datenbank-MLs immer viel netter als auf anderen Listen :)

Schoenen Tag noch

Norbert


Home | Main Index | Thread Index

php::bar PHP Wiki   -   Listenarchive