SQL viel zu langsam

[jobo]

Was sagt der Ausführungsplan?

Ich würde einfach mal einen "normalen" Outerjoin probieren und auf der ehemaligen not exists Menge auf "Null" einschränken. Not exists verwende ich meist nur bei garantiert kleinen Suchmengen, erfahrungsgemäß ist das realtiv selten performant.
Allein die Formulierung der Abfrage bzw. das Verfahren lässt das m.E. erahnen, da es relativ "ungenau" ist. Diese losen Anforderungen durchzuprüfen ist halt aufwendig.

[MyRealName]

Technisch gesehen müsste EXISTS gerade wschnell sein, weil es eine Boolean-Abfrage ist. Count zum Beispiel muss durch alle Register rennen un dir die genaue Anzahl zu sagen, EXISTS nur bis zum ersten Vorkommen.

ich probiere es gerade wie Du sagtest mit einem LEFT JOIN

Code:

SELECT DISTINCT ED1.Item, ED1.Location, ED1.ItemID
FROM EnsambleD ED1
LEFT JOIN EnsambleD ED2 ON (ED1.Itemid = ED2.Itemid AND Ed2.Transcode='EI')
WHERE ED1.Transcode='S '

läuft schon einige Minuten, mal sehen, wann der fertig wird

[MyRealName]

Enttäuschend : gerade schnell ein kleines Programm geschrieben welches das einfach über Locate in einem TVirtualTable macht (also mit 2 VTs). Dauerte ungefähr 10 Sekunden um die Liste zu haben.

Kann Firebird nicht einfach 2 Listen machen und das abgleichen ? Kann doch nicht so schwer sein...

[hoika]

Hallo,

die Frage nach dem Ausführungsplan hast du leider noch nicht beantwortet ...


Heiko

[mkinzler]

Und nach den Indizes auch nicht

[MyRealName]

Den Ausführungsplan sieht man erst nach dem Ausführen.. der führt immer noch aus.
Die Indices haben leider nicht geholfen Hatte sie ja schon auf allen 4 Feldern als es 2 Stunden dauerte...

[Jumpy]

[OT]

Hatte mir das Freitag zufällig mal reingezogen, weil dazu eine Mail von Emba kam. Fand es eigentlich ganz interessant, da es (zwar bezogen auf Oracle) einige Hinweise gibt, wie man die Performance seiner Abfragen verbessern kann.

https://www.youtube.com/watch?v=RMc1...ature=youtu.be

[/OT]

[mkinzler]

Du benötigst einen Index auf Itemid und Transcode. Auf alle 4 und auf die einzelnen hilft ja nichts.

[MyRealName]

Zitat von mkinzler:

Du benötigst einen Index auf Itemid und Transcode. Auf alle 4 und auf die einzelnen hilft ja nichts.

Dieses Query läuft jetzt auch schon 10 Minuten ohne Ergebnis

Fertig nach 11 Minuten

Plan
PLAN SORT (JOIN (ED1 INDEX (ENSAMBLED_IDX_TRANSCODE), ED2 INDEX (ENSAMBLED_IDX1_ITEMID_TC)))

ENSAMBLED_IDX1_ITEMID_TC = Index auf ItemID und Transcode zusammen.

[himitsu]

Zitat:

SQL-Code:

SELECT DISTINCT ED1.Item, ED1.Location, ED1.ItemID
      FROM EnsambleD ED1
      WHERE ED1.TransCode='S ' AND
            NOT EXISTS (SELECT DISTINCT ED2.Itemid FROM EnsambleD ED2 WHERE ED2.Itemid=ED1.Itemid AND ED2.TransCode='EI')

Was mir hier in den Sinn kommt: Ist der Query-Planer eigentlich intelligent genug, um zu erkennen, daß die Ergebnisliste des SubSelects eigentlich garnicht nötig ist?

SQL-Code:

SELECT DISTINCT Item, Location, ItemID
      FROM EnsambleD 
      WHERE TransCode='S ' AND
            NOT EXISTS (SELECT True FROM EnsambleD AS ED2 WHERE ED2.Itemid=EnsambleD.Itemid AND ED2.TransCode='EI' LIMIT 1)