Mailinglisten-Archive |
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
php::bar PHP Wiki - Listenarchive