Avatar von Alvar Freude
  • Alvar Freude

mehr als 1000 Beiträge seit 26.04.2000

Re: Meine Einsendung als komplette/vollständige Version

Hallo,

lamprete schrieb am 28. Juni 2006 15:11

> worauf ich mich bezogen hatte, war:
> > nicht MySQL, das kann zum Beispiel keine Check-Constraints und macht
> > Transaktionen bei auftretenden Fehlern einfach weiter
> also kann es doch Check-Constraints, oder?

nein, kann es nicht -- zumindest steht davon nichts in der
Dokumentation und bei meinem letzten Test ignorierte es die einfach.

> was die Optimierung angeht, denke ich, das MySQL bei Subselects
> wirklich im hintertreffen ist - meine Erfahrungen zeigen auch, dass
> in manchen Fällen der passende Index einfach nicht gefunden wird.

ja; ohne Statistiken über die Daten und einen Query-Planer geht das
ja auch gar nicht.

> Allerdings kann man in sehr vielen Fällen ein Subselect ja auch durch
> ein JOIN ersetzen - und da glaube ich, dass MySQL gar nicht so
> schlecht da steht.

aber da besteht ja das gleiche Problem. Das verschiebt letztendlich
nur die Index-Auswahl auf ein anderes Kriterium -- und bei anderen
Daten ist das dann eben schlechter. Wobei die Datenorganisation meist
so ist, dass dies tatsächlich etwas bringt.

Nur: bei komplexen Joins hilft das auch nicht.

Man kann MySQL Tipps geben bzw. zwingen, bestimmte Indexe zu nutzen.
Nur manchmal klappt selbst das nicht.

> Der Übersichtlichkeit der Query kommt das
> natürlich nicht unbedingt zu gute. Im schlimmsten Fall kann man
> temporäre Tabellen erzeugen, die als Zwischenspeicher dienen. Schön
> ist das natürlich nicht. Wohl aber wirkungsvoll.

oh, das erinnert mich an einen ganz üblen Hack, den ich mal mit
Sybase gemacht habe. Da habe ich in einer Stored Procedure eine
temporäre Tabelle erzeugt, weil es  größere UNIONs nicht als
Subselect annehmen wollte.

> Generell habe ich festgestellt, dass man der 5.0 mehr Hilfen geben
> muss, um die rechtigen Indices zu finden, als es bei der 4.1 der Fall
> war.

Ja; als ich meine große MySQL-Altlast auf die 5er Version umgestellt
habe, hat MySQL angefangen, bei einem relativ simplen Query statt des
entsprechenden Indexes zu nutzen einen kompletten Table-Scan
durchzuführen. Nun, die Tabelle ist mehrere GB groß, und da dauert
das. Dummerweise kommen permanent Schreibzugriffe -- und dank MyISAM
müssen die warten. Und so ist der Server ruck-zuck unbrauchbar ;-)

> Andererseits hat man dann ja auch die grössere Kontrolle
> darüber, was passiert.

naja, der Sinn eines Query-Planers ist ja, dem Entwickler hier unter
die Arme zu greifen und die richtigen Methoden zu wählen. Es geht ja
auch darum, ob zum Beispiel ein Nested Join, Merge, Bitmap-Scan oder
sonstwas schneller ist. Und das kann man irgendwann nicht mehr
vollständig überblicken; erst recht nicht bei sich ändernden Daten.

> Und das EXPLAIN mag vielleicht nicht sogut
> sein, wie bei PostgreSQL, aber auf jedenfall äusserst hilfreich.

besser als nix ;-)
Aber im Vergleich zu PostgreSQL oder Sybase ist das ein Witz, zumal
die Angaben manchmal auch falsch sind.

Ciao
  Alvar

Bewerten
- +
Anzeige