Dann Teste doch einfach mit 2 größeren Testtabellen, dann siehst Du, ob das Verhalten den wenigen Werten geschuldet ist.
Ja. Genau das hat mir tsteinmaurer gestern auch schon nahegelegt. Und das ist sehr sinnvoll.
Und es führt zu einem sehr guten Ergebnis: Ich habe hier eine Datenbank rumliegen in der Messwerte gespeichert werden. Die habe ich zu während des Nachmittags zu testzwecken mal Aktiviert und meine Auftragsdaten reingeschoben (macht in deisem Kontext zwar keinen Sinn, ist aber schön zum testen). Soeben war der Batch fertig. Ich habe dann sofort getestet.
In der
DB gibt es eine Tabelle mit der stolzen Anzahl von 74.530.307 Sätzen.
Ein Feld im Messdatensatz enthält einen Schlüssel aus meiner Auftragsdatei (wie gesagt ca. 240.000 Sätze).
Und siehe da: Es wird ein optimaler Plan gebaut.
select mwrestfeuchte.par,
v2ps.status
from mwrestfeuchte
inner join v2ps on (mwrestfeuchte.par=v2ps.par)
where v2ps.status in ('A','U')
Auch hier sind die Indexe lehrbuchmäßig. Und siehe da: Er verwendet für beide Tabellen den optimalen index und die Statistik ist sehr gut aus:
PLAN JOIN (V2PS INDEX (V2PS_IDX1, V2PS_IDX1), MWRESTFEUCHTE INDEX (MWRESTFEUCHTE_IDX1))
Indexed Reads mwrestfeuchte: 4680
Indexed Reads v2ps: 12
Also an Namenloser, Dejan Vu und all' die anderen: Es ist zu vermuten, dass der Optimizer je nach Tabellengröße "abwägt" wann er "wirklich" was tut.
Sehr beruhigend.
Und nochmal vielen Dank an alle.
Grüße,
Martin
Anything, carried to the extreme, becomes insanity. (Exilant)