Index wird teilweise nicht benutzt

[Dumpfbacke]

Hallo Leute,
ich habe ein Problem das manchmal ein Index nicht benutzt wird. Ich habe den Select einmal vereinfacht. Der Rest wird nicht zu Lösung benötigt und es ist so ggf. einfacher zu lesen

Delphi-Quellcode:

Select Tabelle1.FeldA,Tabelle1.FeldB
From Tabebel1
Left Outer Join Tabelle2 on (gelöscht um es zu vereinfachen )
where Tabebel1.Feld1 is NULL and Tabebel1.Feld2 = 'BA' and
      Tabebel1.Feld3 = 'IX2000' and (Tabebel1.Feld4 = 'AB' or
      Tabebel1.Feld4 = 'AE' or Tabebel1.Feld4 = 'AÄ' or
      Tabebel1.Feld4 = 'AR')
      and Tabebel1.Feld5 is NULL and Tabelle2.Feld9 = '1'

group by Tabelle1.FeldA,Tabelle1.FeldB

Es ist jewals ein extra Index angelegt auf:
Feld1, Feld2, Feld3, Feld4, Feld5, Feld9

Es wird nun nur der Index auf das Feld1 benutzt und ein Indix auf ein Feld9 welche auch in der Join ist. Wenn ich diese Bedingung entferne, also bei der Where das Feld1 entferne so werden als Index alle (restlichen) benutzt.

Wie kann den das sein bzw. warum benutzt Firebid nicht alle angelegten ?


Danke schon mal für die Antworten Tanja

[mkinzler]

Wie kann Feld3 gleichzeitig 'IX2000' und was anderes sein?

Was passiert bei einem Index über alle benötigten Felder?

Ich würde die or durch in ersetzen.

[Bambini]

Zitat:

By default, relational databases ignore NULL values (because the relational model says that NULL means "not present"). So, Index does not store NULL value, consequently if you have null condition in SQL statement, related index is ignored (by default).

http://stackoverflow.com/questions/9...ullable-column

[Dumpfbacke]

Zitat:

Zitat von mkinzler (Beitrag 1344575)

Wie kann Feld3 gleichzeitig 'IX2000' und was anderes sein?

Was passiert bei einem Index über alle benötigten Felder?

Ich würde die or durch in ersetzen.

Danke für den Hinweis. Ich habe den Schreibfehler beseitigt.

Ein Index über alle Felder habe ich nochnicht angelegt. Gibt es dadurch nachteile ?

[Dumpfbacke]

Zitat:

Zitat von Bambini (Beitrag 1344576)

Zitat:

By default, relational databases ignore NULL values (because the relational model says that NULL means "not present"). So, Index does not store NULL value, consequently if you have null condition in SQL statement, related index is ignored (by default).

http://stackoverflow.com/questions/9...ullable-column

Danke für den Hinweis. Ich meinte auch mal so etwas gelesen zu haben. Nur warum wird denn den Index des Feldes 5 benutzt ?

[Bambini]

Zitat:

Zitat von Dumpfbacke (Beitrag 1344586)

Nur warum wird denn den Index des Feldes 5 benutzt ?

Die Optimizer der DB Systeme haben da so ihre Geheimnisse :-D
Wie sieht des der Execution Plan für dieses Statement aus?

[Dumpfbacke]

Zitat:

Zitat von Bambini (Beitrag 1344600)

Zitat:

Zitat von Dumpfbacke (Beitrag 1344586)

Nur warum wird denn den Index des Feldes 5 benutzt ?

Die Optimizer der DB Systeme haben da so ihre Geheimnisse :-D
Wie sieht des der Execution Plan für dieses Statement aus?

Plan
PLAN SORT (JOIN (Tabelle1 INDEX (IDX_FELD1), Tabelle2 INDEX (IDX_FELD9, IDX_FELD9)))

------ Performance info ------
Prepare time = 639ms
Execute time = 1m 13s 539ms
Avg fetch time = 4.085,50 ms
Current memory = 14.478.580
Max memory = 14.634.260
Memory buffers = 800
Reads from disk to cache = 52.880
Writes from cache to disk = 0


Wenn ich die erste Bedingung entferne

Plan
PLAN SORT (JOIN (Tabelle1 INDEX (IDX_Feld4, IDX_Feld4, IDX_Feld4, IDX_Feld4, IDX_Feld4, IDX_Feld5), Tabelle2 INDEX (IDX_Feld9, IDX_Feld9)))

------ Performance info ------
Prepare time = 655ms
Execute time = 3s 291ms
Avg fetch time = 253,15 ms
Current memory = 17.677.420
Max memory = 17.696.404
Memory buffers = 800
Reads from disk to cache = 30.649
Writes from cache to disk = 0

Hier benutze er jeodch auch nicht den Index des Feld2 und Feld 3 was jedoch nicht so tragisch ist da es trotzdem schnell geht.

Warum benutzt er immer nur einen Teil ?

[Bambini]

Zitat:

Zitat von Dumpfbacke (Beitrag 1344606)

Hier benutze er jeodch auch nicht den Index des Feld2 und Feld 3 was jedoch nicht so tragisch ist da es trotzdem schnell geht.

Evtl. spricht die Statistik dagegen diese Indices auch noch zu lesen. Evtl. sind sehr viel gleiche Werte in der Tabelle/Index und dann geht er den Weg die Werte für Feld2 und Feld3 direkt aus der Treffermenge der anderen Indices zu prüfen.

Zitat:

Zitat von Dumpfbacke (Beitrag 1344606)

Warum benutzt er immer nur einen Teil ?

Wenn immer die gleichen Felder abgefragt werden, würde ich versuchen einen zusammengesetzten Index über alle betroffenen Felder zu bauen und nicht für jedes Feld einen eigenen. Die Felder aber nur dann in den Index mit aufnehmen, wenn genügend verschiedene Werte in diesem Feld erwartet werden.

[Dumpfbacke]

Zitat:

Zitat von Bambini (Beitrag 1344610)

Wenn immer die gleichen Felder abgefragt werden, würde ich versuchen einen zusammengesetzten Index über alle betroffenen Felder zu bauen und nicht für jedes Feld einen eigenen. Die Felder aber nur dann in den Index mit aufnehmen, wenn genügend verschiedene Werte in diesem Feld erwartet werden.

Ich habe nun mal einen Index über alle Felder angelegt. Leider benutz er diesen Index nicht. Es benutzt den Index des ersten Feldes. Wenn ich das erset Feld rausnehme bei der Where benutzt er die Index.
Ich verstehe langsam nicht mehr was das Teil da machet ???? :evil:

Tanja

[jobo]

Das kannst Du auch nicht "verstehen", der Optimizeralgorithmus basiert auf (hoffentlich) komplexen Entscheidungen, den Statistiken* und irgendwelchen genialen oder doofen Ideen der Entwickler.
Das bedeutet konkret, die Änderung eines einzigen (!) Feldinhaltes kann den Optimizer dazu bringen, einen anderen Ausführungsplan zu verwenden.

Dein "großer" Index muss demzufolge nicht alle Felder enthalten, nur die wichtigsten. Kleinkram geht auch ohne Index. Es sollte - wie schon oben gesagt- Felder mit hoher Varianz, wenig/kein NULL sein.

*Statistiken: Mengenverhältnisse der Werte in den Feldern der Tabellen.