Doppel-Select-Anweisung zu langsam

[DeddyH]

Wieviele Datensätze sind denn das insgesamt? Und stimmt das Datumsformat? Ich bin gerade nicht mehr sicher, wie das unter MySQL auszusehen hat, hast Du es mal mit SQL-Parametern probiert? Sind Indizes vorhanden?

[Ykcim]

Jetzt hat sich der MySQL-Server vollendst abgeschossen...
Ich versuche es später.

Vielen Dank erst mal

Gruß und schönen Abend
Patrick

[jobo]

einfach mal die Statement Varianten mit

Code:

explain [mysqlstatement]

oder

Code:

explain extended [mysqlstatement]

aufrufen.

Ach nochwas, falls deine Spalte A (das Hauptjoinkriterium also?) offenbar nicht eindeutig ist, sondern nur sowas wie ein Gruppenschlüssel, solltest Du je nach Statement variante aus den vorschlägen noch ein 'distinct' oder 'group by' spendieren, sonst explodiert das Volumen tatsächlich, bei 500T Sätzen sicher unangenehm.
Möglicherweise fallen Dir ja auch noch andere Kriterien ein, die das ganze etwas eindampfen.

[Codehunter]

Ich würde mir mal den Server genauer anschauen:

1. Wie groß ist die Datenmenge, die der Server durch die Anfrage zu verarbeiten hat?
2. Wie viele Datensätze sind zu verarbeiten?
3. Sind für die in den WHERE-Klauseln aufgeführten Felder Indizes gesetzt?
4. Ist dem Server ausreichend RAM zugewiesen? (my.cnf)
5. Wie viel Holz hat die Servermaschine vor der Hütte?
6. Passt die Client-Lib zum Server? (libmysql.dll-Version bzw. UniDAC-Einstellungen)

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

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

Wie lang ist "ungewöhnlich lang"?

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 von Morphie:

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.

[Blup]

Zitat von jobo:

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.

Die Bedingung ist in der View berücksichtigt.

Zitat von jobo:

Und Views bringen hier eher keinen Geschwindigkeitsvorteil.

In diesem Fall schon, sie zwingt den Server die richtigen Dinge in der richtigen Reihenfolge zu machen und nicht den Speicher voll zu müllen. Allerdings sind die beiden Indexe notwendig, sonst bringt alles nichts.