Ausführunsplan / SQL Optimizer

[Dejan Vu]

Zitat:

Zitat von exilant (Beitrag 1267924)

Von Effezienz wage ich hier nicht zu reden. Wenn die Effizienz des Optimierers darin besteht, die kleinere von beiden Tabellen "nach links" zu schieben ist das - mit Verlaub - schon sehr schlicht.

Die guten Dinge sind immer schlicht. ;-)
Woher willst Du denn eigentlich wissen, das das nicht die beste Strategie ist? Du denkst Dir das nur, aber bis ich hier einen Beweis sehe, glaube ich dem Optimizer, ehrlich gesagt, denn der rechnet wenigstens.

Mach doch mal Folgendes: Kopiere die Tabellen einfach und erzeuge die in deinen Augen optimalen Indexe, aber vermeide oder deaktiviere den Index, der in deinen Augen vom Optimizer falsch verwendet wird und bringe den Optimizer einfach dazu, dir zu gehorchen. Dann vergleiche die beiden I/O-Statistiken. Vielleicht wird man schlau draus und tritt die Schlichtheit des Optimizers doch in die Tonne.

Glauben kann Jeder (macht die Menschheit auch überwiegend). Aber *wissen* und *beweisen* machen wenige.

[exilant]

Zitat:

Zitat von mkinzler (Beitrag 1267925)

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

[exilant]

Zitat:

Zitat von Dejan Vu (Beitrag 1267929)

Die guten Dinge sind immer schlicht. ;-)

Das ist auch in diesem Fall wohl so.

Danke,
Martin

[Dejan Vu]

Der Programmteil im Compiler (der aus einem SELECT einen ausführbare Struktur erzeugt), nennt sich ja 'Optimizer'. Der optimiert wirklich, d.h. er wählt anhand der Index- und I/O-Statistiken (und diversen anderen Werten) den vermeidlich optimalen Ausführungsplan aus. Das geht meist über Brute-Force, d.h. der Algorithmus probiert nicht alle Kombinationen durch. Trotzdem dauert es ein paar ms, bis der Plan fertig ist, weswegen es sich lohnt, seine aus der Anwendungen kommenden Anweisungen per 'prepare' vorzukompilieren. Dann wird einmalig ein Query-Plan angelegt.