Ausführunsplan / SQL Optimizer

[exilant]

Hallo zusammen,

ich habe da ein Problem mit einer harmlosen Query:

select
v2ps.par,
v2ps.v2fertigartikel,
v2fertigartikel.artikelbezeichnung
from v2ps
inner join v2fertigartikel on (v2ps.v2fertigartikel=v2fertigartikel.id)
where v2ps.status in ('U','A')

Ein ganz simpler Fall. Betriebsaufträge bestimmter Stati werden mit Artikelstammdaten verknüpft. Selbstverständlich funktioniert diese Abfrage und liefert das korrekte Ergebnis. Aber wenn ich mir den Ausführungsplan in IBExpert ansehe steht da:

Plan:
PLAN JOIN (V2FERTIGARTIKEL NATURAL, V2PS INDEX (V2PS_IDX3))

NATURAL??? In der Tabelle V2FERTIGARTIKEL ist das Feld ID vom Typ integer und der Primärschlüssel. Der dazugehörige Index heisst RDB$PRIMARY46. Warum wird dieser Index nicht benutzt? Bei größeren Datenmengen könnte das zum ernsten Problem werden. Ober habe ich da ganz grundsätzlich missverstanden oder übersehen?

Vielen Dank,
Martin

[gmc616]

Ist v2ps.v2fertigartikel ebenfalls integer? Liegt dort ebenfalls ein index drüber?

Oder versuch doch mal so:

Code:

select 
    v2ps.par,
    v2ps.v2fertigartikel,
    v2fertigartikel.artikelbezeichnung
from 
    v2ps,v2fertigartikel 
where 
    v2ps.status in ('U','A')
and v2ps.v2fertigartikel=v2fertigartikel.id

[exilant]

@gmc616: Danke für deine Antwort. Natürlich ist das Feld vom Typ integer. Leider nicht als FK definiert obwohl es an dieser Stelle Sinn machen würde. Aber das sollte keinen Einfluss auf den Optimizer haben.
Deine Abfrage führt zum gleichen Plan. Es ist also egal ob mit JOIN oder WHERE die Tabellen verbinde. Es bleibt bei NATURAL.
Ich bin echt ratlos.

[gmc616]

Sorry, ich bin in FB nicht fit, nutze ihn garnicht.

Die Überlegung war, dass evtl. die beiden IDs unterschiedliche Integer (smallint, longint etc.) sein könnten und deswegen FB einen eigenen Index zusammen baut.
Die Erfahrung zeigt auch, das manchmal ein einfaches umbauen des Statements die SQL-Engine dazu veranlasst, anders zu arbeiten ( z.B. die andere Tabelle indiziert ).

z.B. einfach mal umdrehen

Code:

v2fertigartikel.id=v2ps.v2fertigartikel

oder das FROM umstellen ...

oder evtl. einen FK zusätzlich über v2fertigartikel.id

ist aber alles nur geraten, wie erwähnt, kenne/nutze ich FB nicht.

[exilant]

Die Felder sind beide als INTEGER NOT NULL deklariert. Ein Umdrehen des Vergleiches habe ich auch schon versucht. Das bringt nichts. Ich wäre aber auch schreiend aus dem Fenster gesprungen wenn das funktioniert hätte....
Ich werde jetzt mal das mit dem FK probieren. Allerdings laufen ein paar ältere Anwendungen auf der Datenbank. Da bin ich mir nicht sicher welche Seiteneffekte ich mir mit der Deklarion des FK einhandle. Ich sehe die Exceptions durch constraints violations schon vor meinem geistigen Auge.
Schaun mer mal.
Trotzdem Danke,
Martin

[Namenloser]

Kann es sein, dass auf v2ps.status auch ein Index ist, und er diesen im ersten Schritt (bevor er den eigentlichen Join durchführt) verwendet, um die Zeilen von v2ps anhand der where-Bedingung einzugrenzen? Dann kommen anschließend die ids unsortiert heraus, sodass er keinen Merge-Join durchführen kann (und daher von den Indizes auf den id-Spalten nicht profitiert).

Vorausgesetzt, ich habe diesen Query Plan überhaupt richtig interpretiert... habe auf die Schnelle irgendwie keine Dokumentation dazu gefunden, wie diese Ausgabe überhaupt zu lesen ist.

Ich würde auf jeden Fall mal die Where-Bedingung testweise weglassen, um zu gucken, was passiert.

[Dejan Vu]

Vielleicht ist die Tabelle 'v2FertigArtikel' zu klein?

[exilant]

Zu klein ist so eine Sache. Im Augenblick sind knapp 8.000 Datensätze drin.
Die Performance der Abfrage ist im Augenblick auch kein Problem. Der Firebird läuft auf einer Mödermaschine unter Ubuntu Server. Granatenschnell. Aber die Datenmenge wird bald steil nach oben gehen. Ich rechne mit mehr als 1.500 neuen Einträgen/Monat ab Ende des Jahres.
Und es geht auch um das Grundsätzliche. Ich sehe da ein Problem.

[exilant]

@Namenloser: Ja. Auf Feld STATUS gibt es einen Index. Warum das aber dazu führen sollte dass der Index für den PK in v2fertigartikel nicht benutzt wird ist mir nicht klar.
Es ist eine simple 1-1 Beziehung.
Aber trotzdem Danke.

[p80286]

Vielleicht ist hier etwas für Dich zu holen?

Gruß
K-H

P.S.
Das Umstellen der Tabellenreihenfolge im FROM kenn ich noch von den älteren MSSQL-Servern, da waren Abfragen noch handoptimiert.