@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.
Weil der Nutzen des Index beim Join, soweit ich weiß, hauptsächlich darin besteht, dass durch ihn beide Relationen bezüglich der Verknüpfungs-Spalte sortiert sind. Dadurch kann man einen recht effizienten Merge-Join durchführen.
Folgende Tabellen als Beispiel:
Code:
Tabelle X Tabelle Y
A B A C
--------- ---------
1 42 2 0
2 27 3 1
3 40 4 2
5 38 5 3
7 39 7 4
9 41 9 5
Beide Tabellen haben einen Index auf Spalte A (aufsteigend sortiert), und die Abfrage ist
select A, B, C from X join Y on X.A = Y.A
.
Man geht nach folgendem Pseudocode vor:
Code:
CursorX := Zeiger auf erste Zeile von Tabelle X.
CursorY := Zeiger auf erste Zeile von Tabelle Y.
while (not CursorX.EOF and not CursorY.EOF) do
begin
if CursorX.A = CursorY.A then
Elemente von CursorX und CursorY konkatenieren und Zeile ausgeben
else if CursorX.A > CursorY.A then
CursorY eine Zeile weiter nach unten bewegen
else if CursorX.A < CursorY.A then
CursorX eine Zeile weiter nach unten bewegen
end;
(Zur Vereinfachung gehe ich hier mal davon aus, dass A in beiden Tabellen unique ist. Man kann den Algorithmus aber auch für nicht-unique Fälle verallgemeinern).
Das ist ein recht effizienter Join-Algorithmus, allerdings nur dann wirklich effizient, wenn die es für die Eingabemengen schon sortiert sind. Im obigen Beispiel ist das der Fall dank des Index.
Wenn die Abfrage jetzt aber stattdessen wäre
select A, B, C from X join Y on X.A = Y.A where X.B in (42, 27, 38, 39)
und auf B ein Index liegt, dann kann es sein, dass der Optimizer sich entscheidet erst mal nach der Bedingung zu filtern und dabei den Index auf B zu nutzen.
Zwischenergebnis:
Code:
Tabelle X' Tabelle Y
A B A C
--------- ---------
2 27 2 0
5 38 3 1
7 39 4 2
1 42 5 3
7 4
9 5
Da der Index auf B benutzt wurde, sind die Zeilen von X' nun möglicherweise in einer anderen Reihenfolge und nicht mehr nach A sortiert. Folglich kann der Join nun nicht mehr so effizient mit dem Merge-Join-Algorithmus durchgeführt werden. Man könnte jetzt natürlich X' einfach noch mal extra nach A sortieren, aber möglicherweise ist es effizienter, gleich einen ganz anderen Join-Algorithmus zu verwenden, z.B. Hash-Join. Dabei nützt einem dann allerdings auch der Index auf Tabelle Y nichts mehr, weshalb er nicht benutzt wird.
Ist aber nur geraten, ich hab keine Ahnung, was der Optimizer intern macht und was für Algorithmen er verwendet.