Abfrage mit verketteten OR-Verknüpfungen bringt MySQL zum Absturz..

Die zweite Abfrage ergibt tastächlich eine leere Menge, aber die erste Abfrage enthält viele id's welche nicht eindeutig, also mehrfach vorhanden sind. Da lag ich wohl falsch..
 
Werbung:
Da lag ich wohl falsch
Liegen ist hier sowieso nicht so die optimale Herangehensweise.
Falsch liegen ist eigentlich immer suboptimal ;)

Und jetzt?
Was ist mit Explain Plan?
Was ist mit der Maschine, auf der es läuft? Ein Raspberry?
Wie ist sie konfiguriert?

Was geschieht, wenn Du die Abfrage auf spezifische ID einschränkst?
 
Es ist ein Server mit einem Intel Xeon E5620 und 32GB RAM (Ob DDR2 oder sogar DDR weiß ich nicht, der Server ist echt alt). Ich denke nicht, dass es an der Hardware scheitert, oder?
Welche Konfiguration meinst du genau? Ich hatte damit bis jetzt nichts zu tun. All die Jahre gab es keine Probleme mit Abfragen, auch große Datenmengen werden problemlos ausgegeben.

Was meinst du genau mit Explain Plan?

Die Abfrage funktioniert mit spezifischen id's, innerhalb von 60 Millisekunden gibt er mir das Ergebnis aus.
 
Welche Konfiguration meinst du genau? Ich hatte damit bis jetzt nichts zu tun. All die Jahre gab es keine Probleme mit Abfragen, auch große Datenmengen werden problemlos ausgegeben.
Na komm schon, Du willst Hilfe, nicht das Forum.
Wenn es so ein fetter Server ist, kann er trotzdem wie ein Raspberry konfiguriert sein.

Wenn Du Explain probierst, baue am besten gleich die Abfrage auf einen expliziten Join um , wie ebenfalls bereits empfohlen.
Und vielleicht lässt du auch mal das Sternchen bei der Select Clause für dateien weg. Sind da wirklich dateien drin? Also BLOB?
Und wenn, besonders wenn früher alles besser war, hat vielleicht irgendein Schelm neulich mal ein paar DVD ISO Images dort abgespeichert?
Hast Du mal geprüft, ob das Filesystem des Servers ein plausibles Antwortverhalten zeigt? Vielleicht gibt's ein Plattendefekt im RAID oder sowas?
 
Ich gehe mal davon aus, dass der problematische Query gemeint ist. Das hatte ich ja vorher im Thread auch gemacht und die Ergebnisse gepostet, deshalb war ich verwirrt.

Also, ich tippe jetzt mal alles ab was der Explain Befehl mir ausgibt:
select_type table partitions type possible_keys key key_len ref rows filtered Extra
SIMPLE dateien NULL ALL PRIMARY NULL NULL NULL 47.300 1,11 Using where
SIMPLE daten NULL eq_ref Primary,idxID,idxso PRIMARY 66 xxx.dateien.id 1 5,00 Using where
 
Es sind keine echten dateteien, sondern nur Pfade gespeichert.
Ich habe ein komplett neues Projekt bekommen, wobei ich bestimmte Abfragen generieren muss, die vorher nicht verwendet wurden. Die Abfragen, die davor genutzt wurden, funktionieren immernoch. Eine große Veränderung gab es also nicht.
 
Ich gehe mal davon aus, dass der problematische Query gemeint ist. Das hatte ich ja vorher im Thread auch gemacht und die Ergebnisse gepostet, deshalb war ich verwirrt.

Also, ich tippe jetzt mal alles ab was der Explain Befehl mir ausgibt:
select_type table partitions type possible_keys key key_len ref rows filtered Extra
SIMPLE dateien NULL ALL PRIMARY NULL NULL NULL 47.300 1,11 Using where
SIMPLE daten NULL eq_ref Primary,idxID,idxso PRIMARY 66 xxx.dateien.id 1 5,00 Using where

Tja, viel sagt das halt nicht aus. Vielleicht kann jemand das besser deuten als ich, die Tabelle 'daten' wird aber offenbar via dem Primary Key - Index abgefragt, oder?
 
Werbung:
Ok, das explain Ergebnis ist (für mich) nicht erhellend.
Was ergibt die Abfrage unten? Läuft sie durch? Wieviel Datensätze erwartest Du?
Code:
select count(*)
  from (SELECT daten.s0  AS parent_id,
               daten.s1  AS kunden_nr,
               daten.s2  AS kunde,
               dateien.*
          FROM dateien, daten
         WHERE (daten.s0 = 'oksur-68930' OR daten.s0 = 'lwgtv-08945' OR
               daten.s0 = 'gjqfd-68005' OR daten.s0 = 'zsdgt-22330' OR
               daten.s0 = 'cgdasr-45670' OR daten.s0 = 'tttss-21502')
           AND daten.s49 = "RG"
           AND daten.id = dateien.id
           AND dateien.geloescht = "n"
           AND dateien.bezeichnung LIKE ("%Protokoll")) x

Was ist mit dem Umbau auf JOIN?
Ein expliziter JOIN ermöglicht es dem Optimizer zumindest, etwas gezielter zu optimieren. Ob das hier wirkt, weiß ich nicht.

Hast Du schon mal auf den Server geschaut? Dateisystem, Logfiles, Prozesslast, Prozesslast bei dieser Abfrage..?
Windows oder Linux Server?
 
Zurück
Oben