Doppel-Select-Anweisung zu langsam

[Blup]

"In" ist extrem teuer (Zeitaufwand).
Ich würde die Abfrage in eine View für das Auswahlkriterium

Code:

/* Index über SpalteDatum erforderlich */
CREATE VIEW V_SpalteA2012(
    SpalteA)
AS
Select SpalteA from Tabelle1 where SpalteDatum between '20120101' and '20121231';

und in die eigentliche Datenabfrage aufteilen:

Code:

/* Index über SpalteA erforderlich */
select    b.*
from      V_SpalteA2012 a
left join Tabelle1      b on b.SpalteA = a.SpalteA

[jobo]

Auch wenn der TE scheinbar einen Herzanfall hatte oder noch dabei ist, den Server wieder betriebsbereit zu machen:

Das ist nun das "vermutlich" 3. verschlimmbesserte Statement, deshalb bitte noch mal meinen vorigen Beitrag berücksichtigen.

"Vermutlich" deshalb, weil ein paar Detailangaben des TE fehlen. Sein ursprüngliches SQL ist hier sehr wahrscheinlich das einzig formal richtige, das implizit (durch das IN) ein Distinct auf die Menge macht. Alle anderen Statements machen das nicht und würden bei einer Grundmenge von 500T Sätzen solange daten permutieren, bis der Tablespace voll ist.

Distinct wäre also bei den beiden Vorschlägen zu ergänzen. Ich würde den von p80286 plus Distinct im Subselect nehmen. Und Views bringen hier eher keinen Geschwindigkeitsvorteil.

[Morphie]

Ich werfe es jetzt mal einfach in den Raum:
Wir hatten letzte Woche auch Performanceprobleme mit MySQL. Eine stinknormale Abfrage hat trotz richtiger Indizierung usw. ungewöhnlich lange gedauert. Dieses Problem lies sich mit mehreren Datenbeständen (Kunden) und mehreren MySQL-Versionen reproduzieren.

Ich habe dann mal eine Migration zu MariaDB (hat ca. 10 Minuten gedauert) durchgeführt. Bei MariaDB dauert exakt der selbe Befehl nur noch 0.0x Sekunden. Wir stampfen MySQL jetzt ein und verwenden nur noch MariaDB. Am Code mussten wir übrigens nichts ändern, da war MariaDB tatsächlich 100%ig kompatibel.

[Codehunter]

Zitat:

Zitat von Morphie (Beitrag 1202087)

[...] ungewöhnlich lange gedauert [...]

Wie lang ist "ungewöhnlich lang"?

Zitat:

Zitat von Morphie

Bei MariaDB dauert exakt der selbe Befehl nur noch 0.0x Sekunden.

Die kochen doch auch nur mit Wasser. War es auch exakt der selbe Datenbestand und Tabellenstruktur?

Zitat:

Zitat von Morphie (Beitrag 1202087)

Wir stampfen MySQL jetzt ein und verwenden nur noch MariaDB.

So sehr ich MariaDB auch schätze, so schnell würde ich das nicht ändern. Vorallem Aussagen wie 100% kompatibel machen mich nachdenklich. Es gibt immer Unterschiede. Die Frage ist, ob diese für das eigene Projekt relevant sind.

[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:

Zitat von Codehunter (Beitrag 1202090)

Wie lang ist "ungewöhnlich lang"?

Also für ein normales Select mit ein paar Where-Bedingungen auf indizierte Felder dauerte die Abfrage ca. 8 Sekunden.
Ist natürlich kein Vergleich zum Problem vom TE, aber im Vergleich zu den 0.0x Sekunden auf MariaDB schon ziemlich krass. Das hat uns echt gewundert.

Zitat:

Zitat von Codehunter (Beitrag 1202090)

Die kochen doch auch nur mit Wasser. War es auch exakt der selbe Datenbestand und Tabellenstruktur?

Ja, die exakt gleichen Daten mit exakt der gleichen Tabellenstruktur. Und dieses Phänomen lies sich halt bei diversen Kunden reproduzieren. Wir haben wie gesagt nichts am Projekt / der Datenstruktur geändert. Lediglich den Dienst MySQL zu MariaDB getauscht.

Zitat:

Zitat von Codehunter (Beitrag 1202090)

So sehr ich MariaDB auch schätze, so schnell würde ich das nicht ändern. Vorallem Aussagen wie 100% kompatibel machen mich nachdenklich. Es gibt immer Unterschiede. Die Frage ist, ob diese für das eigene Projekt relevant sind.

Wir haben alle Projektteile getestet und haben keinen negativen Unterschied feststellen können. Das mag natürlich in Spezialfällen anders aussehen. Einen Versuch ist es aber immer wert. Schon allein weil man nicht an Oracle gebunden ist ;-)

[Morphie]

Zitat:

Zitat von jobo (Beitrag 1202092)

@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...