AW: Select zu komplex für mysql

[Andreas Müller]

Hallo Andreas,

zunächst möchte ich kurz festhalten das es hier um MySQL geht und nicht um
Postgres.

> Dir ist schon klar, daß auch die Reihenfolge eine Rolle spielen kann
> und
> Einfluß auf die Größe von Zwischenergebissen hat?
> 
> http://www.postgresql-support.de/pgbook/node498.html

Im Prinzip bei vollkommen offenen INNER-Joins stimmt das. Hier scheint aber
eine Abfragerichtung vorgegeben zu sein. Allein der Umstand
"t1.property_qwidget_key=2" sorgt für eine Ausrichtung des Optimizers
(Konstanten werden wenn möglich bevorzugt). Weiterhin ist die Abfrage hier
in ihrer logisch sinnvollen Reihenfolge bereits formuliert. Daher sehe ich
gerade da wenig Handlungsbedarf.

> > welcher Index an welcher Relation zu verwenden ist.
> 
> Das geht wie?

Siehe http://dev.mysql.com/doc/refman/5.1/de/select.html bzw.
http://dev.mysql.com/doc/refman/5.1/de/join.html

Allgemein sieht das so aus: tbl_name [[AS] alias] [{USE|IGNORE|FORCE} INDEX
(key_list)]

> > Der einzige sinnvolle Schritt in dem Problem ist die Analyse des
> > "explain". Danach müsste man die Index-Situation prüfen ob an allen
> 
> Leider hat der Planner kein Kostenmodell wie z.B. bei PG.

Der MySQL Optimizer mag kein Kostenmodell wie PG haben - aber er hat eins.
Genau dafür werden die Index-Statistiken verwendet. Darüber wird versucht
abzuschätzen wie teuer welche Operation ist.

> > sinnvollen und notwendigen stellen die richtigen Indizes vorhanden
> > sind. Stimmt dann alles und "explain" liefert noch immer "Müll" oder
> 
> Bei Tabellen mit 2-3 Zeilen, wie vom Fragesteller geschrieben, bringen
> Indexe genau wie viel Vorteil?

Zum Teil sehr viel. Nimm mal die Beispiel-Query und bewerte mal jeden JOIN
mit der Satzsanzahl 3 und rechne mal den schlechtesten Fall bei einem
Full-Table-Scan aus. Dann schreib mal an jedes Schlüsselfeld gejointen
Tabelle eine 1 und rechne erneut.

Außerdem kennen wir nur die Menge der Datensätze in der Haupttabelle "
property_qwidget as t1". Die Mächtigkeit der anderen Tabellen kennen wir
nicht!

Da ich es letzten vergessen hatte: Es ist hier nicht ganz unwichtig zu
wissen ob es sich um MyISAM oder InnoDB als Storage-Engine handelt. In der
verwendete Version existiert noch ein Bug im Optimizer wenn es sich im
InnoDB handelt. Der Bug ist gefixt aber leider kann ich gerade nicht genau
sagen ob der Fix in der aktuellen 5.1.36 bereits enthalten ist oder erst in
der nächsten Version.

LG,
Andreas

PS: Vielleicht wäre es sinnvoll über MySQL zu diskutieren und nicht immer
wieder anzufangen was doch bei PG alles anders und vielleicht besser ist.
Das hilft bei der Problemlösung nämlich keinen Millimeter.


_______________________________________________
Allgemeine Infos zur Liste: http://www.4t2.com/mysql/
Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de