Doppel-Select-Anweisung zu langsam

[jobo]

@MAriaDB
Mmh, ich arbeite nicht produktiv mit mySQL. Aber die Erfahrung zeigt: Jedes RDBMS hat seine Schwächen, das sind ganz selten harte Fehler bei der SQL Auswertung, aber häufig "obskures" Verhalten der Optimizer.

Hat man sich in einem System "eingearbeitet", also an seine Macken gewöhnt, kann man bezüglich der heimlichen Schwachstellen auch leicht vom Regen in die Traufe geraten.

Einen solchen Schwenk würde ich nur nach gründlichen Tests machen.
Andererseits ist ja im Zeitalter von JPA das RDBMS zur Blackbox verkommen und unschlaues SQL wird durch mehr Transistoren, SSD Cache & Co ersetzt.

[Morphie]

Zitat von jobo:

@MAriaDB
Mmh, ich arbeite nicht produktiv mit mySQL. Aber die Erfahrung zeigt: Jedes RDBMS hat seine Schwächen, das sind ganz selten harte Fehler bei der SQL Auswertung, aber häufig "obskures" Verhalten der Optimizer.

Glaub mir, wir saßen Tagelang dabei, die SQL-Abfrage zu optimieren.
Wir haben am Ende sogar ganz perverse Dinge versucht (IIFs anstatt Wheres,...) doch letztendlich war es definitiv ein Problem von MySQL.

Wir waren auch ziemlich erstaunt, dass ein Fork so viel schneller ist.
Btw. nachdem wir die Kunden auf MariaDB umgestellt haben, lief das gesamte Programm auch merklich schneller. Der Geschwindigkeitszuwachs beschränkt sich also nicht nur auf diese eine Abfrage!
Wir sind seitdem begeistert... Vor allem weil es auch wirklich schnell umgestellt ist.

Edit:
Hier mal das SQL-Statement:

Code:

SELECT SUM(POSITIONEN.MENGE)
FROM POSITIONEN INNER JOIN BELEGE ON (POSITIONEN.BELEGNR = BELEGE.BELEGNR)
WHERE POSITIONEN.ARTIKELNR = '1090213000' AND BELEGE.BELEGART = 'A'

Unter MySQL: /* 0 rows affected, 1 rows found. Duration for 1 query: 7,753 sec. */
Unter MariaDB: /* 0 rows affected, 1 rows found. Duration for 1 query: 0,078 sec. */

Belegart, Artikelnr und Belegnr sind natürlich indiziert.

[jobo]

Glaube ich gern, es wäre sonst ja etwas unverantwortlich.
Gerade bei MySQL und Maria ist ein Tausch ja auch naheliegend, auch bzw. vor allem ohne Nutzung von JPA/Hibernate.

Maria würde im obigen Fall (SQL Alternativvorschläge) allerdings genauso die Daten permutieren. Korrektes SQL steht also erstmal am Anfang.

[Codehunter]

Was natürlich sein kann: Beim MySQL die Community-Edition eingesetzt statt der Professional. Erstere ist in vielen Punkten (mehr oder weniger absichtlich) nicht so gut optimiert wie die Pro-Version. Soll wohl so ein orakelsches Marketing-Argument für das größere MySQL oder sogar OracleDB sein. Darum könnte ich mir denken, dass der Performance-Vergleich zwischen MySQL-Pro und MariaDB kaum noch nennenswerte Unterschiede zeigen würde.

[Morphie]

Da hast du recht, wir haben hier nur den Community-Server.
Ich lade mir mal die Trial vom Enterprise-Server herunter und teste dann noch mal

edit: wobei wir niemals einen kostenpflichtigen Server kaufen würden, wenn es den bei MariaDB "umsonst" gibt...

[Morphie]

So, Enterprise Server heruntergeladen und installiert.

Seltsamerweise ist der sogar noch langsamer als der Community-Server.
Ich habe den SQL-Dump also ganz frisch auf dem Enterprise-Server eingelesen. Keine Daten(banken) übernommen!

Vorsichtshalber habe ich die Abfrage gleich 3x hintereinander durchgeführt:

Zitat:

SELECT SUM(POSITIONEN.MENGE) FROM POSITIONEN INNER JOIN BELEGE ON (POSITIONEN.BELEGNR = BELEGE.BELEGNR) WHERE POSITIONEN.ARTIKELNR = '1090213000' AND BELEGE.BELEGART = 'A' ;
/* 0 rows affected, 1 rows found. Duration for 1 query: 9,048 sec. */

SELECT SUM(POSITIONEN.MENGE) FROM POSITIONEN INNER JOIN BELEGE ON (POSITIONEN.BELEGNR = BELEGE.BELEGNR) WHERE POSITIONEN.ARTIKELNR = '1090213000' AND BELEGE.BELEGART = 'A' ;
/* 0 rows affected, 1 rows found. Duration for 1 query: 15,538 sec. */

SELECT SUM(POSITIONEN.MENGE) FROM POSITIONEN INNER JOIN BELEGE ON (POSITIONEN.BELEGNR = BELEGE.BELEGNR) WHERE POSITIONEN.ARTIKELNR = '1090213000' AND BELEGE.BELEGART = 'A' ;
/* 0 rows affected, 1 rows found. Duration for 1 query: 11,841 sec. */

Ich habe mir mal den Ausführungsplan anzeigen lassen
MySQL Enterprise:

Code:

id   select_type   table        type     possible_keys               key         key_len    ref                             rows     filtered   Extra
1   SIMPLE        POSITIONEN   ref      PRIMARY,artikelnr,belegnr   artikelnr   53        const                           16160   100.00    Using where
1   SIMPLE        BELEGE       eq_ref   PRIMARY,belegart            PRIMARY     52        POSITIONEN.belegnr              1       100.00    Using where

MariaDB:

Code:

id   select_type   table        type     possible_keys               key         key_len    ref                             rows     filtered   Extra
1   SIMPLE        POSITIONEN   ref      PRIMARY,artikelnr,belegnr   artikelnr   53        const                           16160   100.00    Using index condition
1   SIMPLE        BELEGE       eq_ref   PRIMARY,belegart            PRIMARY     52        POSITIONEN.belegnr              1       100.00    Using where

MariaDB macht also irgendwas anders als MySQL.
Kann man dieses Verhalten MySQL beibringen? ("USE INDEX" oder ähnliches?)

[Codehunter]

Das geht ziemlich in die Interna, da müßte man wahrscheinlich mal direkt bei MariaDB anfragen. (Bei MySQL solltest du damit lieber nicht landen denke ich *gg*)

[jobo]

Zitat von Morphie:

So, Enterprise Server heruntergeladen und installiert.

Seltsamerweise ist der sogar noch langsamer als der Community-Server.
Ich habe den SQL-Dump also ganz frisch auf dem Enterprise-Server eingelesen. Keine Daten(banken) übernommen!
MariaDB macht also irgendwas anders als MySQL.
Kann man dieses Verhalten MySQL beibringen? ("USE INDEX" oder ähnliches?)

Index hints
http://dev.mysql.com/doc/refman/5.0/en/index-hints.html

Dein Vergleich ist glaub ich etwas unfair. Eine frische Datenbank hat idR. noch keine Statistiken aufgebaut und die Optimizer Entscheidungen können die Selektivität eines Index nicht berücksichtigen. Hab kein Plan, was man da bei mysql alles anwerfen muss, aber es sollte sich bei größeren Datenmengen schon lohnen, die Statistiken zu fahren.