Anonym.
Hallo Forum,
Stimmt folgende Aussage?
Auf einer Tabelle liegt ein Index IFeld1, IFEld2, IFeld3.
Ein Select auf diese Tabelle mit
…WHERE IFELD2 Â = ..
    AND IFELD3 = …
    AND IFELD1 = …
ist langsamer als ein SELECT mit
…WHERE IFELD1 Â = ..
    AND IFELD2 = …
    AND IFELD3 = …
Gibt es da wirklich Performanceuterschiede?
Merkt DB2 im ersten SELECT nicht, daß der Index benutzt werden muß?
Danke für die Antwort
Gruß
Perix
Hi Perix,
;D wer erzählt denn so etwas? Und um welches RDBMS bzw. welche Version geht es hier? 😮
Ob DB2 unterschiedliche Zugriffspfade benutzt, ist mit einem Explain schnell zu ermitteln. Für die Index-Nutzung ist übrigens auch wichtig, was rechts vom Gleichheitszeichen steht oder ob die Datentypen des Prädikats übereinstimmen. Die reine Reihenfolge der Prädikate in der genannten WHERE-Klausel ist unwesentlich.
MfG
H.A. Pürner
Hi Axel,
so wie Du es beschreibst, kenn ich es auch.[smiley=thumbup.gif] Dieses Thema kam bei einem Meeting hoch und es handelte sich eben um DB2 (neuste Version 7 ?)
Ãch konnte mir auch nicht vorstellen, daß DB2 so blöd ist und den Index nicht erkennt, obwohl alle Spalten (wenn auch nicht in derselben Reihenfolge) vorhanden sind.
btw.
nimmt DB2 eigentlich die erste Bedingung und rennt dann los und kommt mit einer Lösungsmenge, auf die dann die 2. Bedingung angewendet wird usw.
Oder wird die gesamte Bedingung erst mal analysiert und erkannt, daß die erste Filterung mit dem ersten Indexfeld am schnellsten ist
GRuß
Perix
Hi Perix,
wer auch immer das erzählt haben mag, hat wahrscheinlich nur Erfahrungen mit einem Produkt, das früher für seinen rule-based "Optimizer" berüchtigt war und viele Hints benötigte. 😉
Oder war’s ein orientalischer Märchenerzähler mit langem Bart? 😎
Ein kostenbasierter Optimizer, wie DB2 ihn seit Anfang an besitzt, muß den gesamten Befehl mit allen Prädikaten analysieren, um dann die möglichen Zugriffswege zu finden und mit Kosten zu bewerten – und dann den vermeintlich billigsten Pfad (Irrtum eingeschlossen ::) ) zu finden.
Wie gesagt, Explain bietet den Beweis, ob die verschiedenen Formulierungen gleichwertig sind. In DB2 for LUW bietet Visual Explain sogar den nach Analyse umformulierten SQL-Befehl zum Vergleich an.
MfG
AxelP
PS: Randbedingungen für ein "normales" Verhalten sind das Vorhandensein von Katalogstatistiken und eine entsprechende Tabellengröße (> 15 Pages o.ä.). Für kleine Tabellen wird ein Index nicht genutzt, weil unwirtschaftlich.
Moin,
es gibt Tage, da wäre ich froh, wenn DB2 so einen RULE-Hint hätte. Der "andere" Optimizer gibt einem zwar immer wieder Rätsel auf, aber mit richtigen Hint tut er dann doch, was man sich selber so vorgestellt hat. Und ich habe bei der "anderen" Datenbank auch noch nie die Systemtabellen updaten müssen, um den Optimizer zu beinflussen 😉
Der DB2-Optimizer ist für mich immer noch ein Buch mit 7 Siegeln. Da wird sicher ’ne ganze Menge Intelligenz hinter stecken, aber manchmal kommt mir der Verdacht, dass das alles nur fuzzy ist. Kann aber auch daran liegen, dass wir SAP machen, und mit der Mandanten-Spalte in jedweder Abfrage würde ich auch durcheinander kommen.
Kay
Hi Kay,
wenn wir dasselbe RDBMS meinen, so war es bis V9 auch nötig, die Katalogstatistiken zu füllen, aktuell zu halten und ggfs. Histogramm-Statistiken zu sammeln, damit der kostenbasierte Optimizer auch korrekt arbeitete. In V10 ist da vieles automatisiert worden (wie in DB2 LUW 8.2 und 9 auch – und unter z/OS gibt es ja Realtime-Statistiken) – und der regelbasierte Optimizer ist endlich tot.
Mandaten-Spalten in Tabellen sind immer ein Problem, besonders wenn man nur einen oder eine Hand voll Mandanten hat. Leider werden Indizes nicht nach technischen Gesichtspunkten, sondern nach fachlichen strukturiert, so daß die Mandaten-Spalte dann an erster Stelle steht. Mit ihrer meist lausigen Kardinalität (1 – 5) verdirbt sie dann fast jede Indexnutzung! 😮
Es gibt übrigens Seminare über die DB2-Optimizer (z/OS und LUW), in denen Evaluierung von Prädikaten, Join-Verfahren, Bewertung von Zugriffen etc. erläutert werden. (Ich halte auch solche Seminare 😉 )
MfG
AxelP
You must be logged in to reply to this topic.
