Index bei Like

[Dumpfbacke]

Hallo Leute,
sagt einmal warum benutze Firebird bei einer Abfrage wie z.B.

Delphi-Quellcode:

Where Strasse like 'Hauptstr%'

keinen Index auch wenn einer vorhanden ist ?

Tanja

[vagtler]

Benutze stattdessen

Code:

Where Strasse starting with 'Hauptstr'

Der Plan bei Einsatz von Like benutzt keinen Index, da der Like-Parameter auch mit einer Wildcard anfangen könnte - und da nützt ein Index nichts.

[Bernhard Geyer]

Zitat:

Zitat von vagtler (Beitrag 1239001)

Benutze stattdessen

Code:

Where Strasse starting with 'Hauptstr'

Der Plan bei Einsatz von Like benutzt keinen Index, da der Like-Parameter auch mit einer Wildcard anfangen könnte - und da nützt ein Index nichts.

Wenn der SQL-Parser so dumm ist (kommt ab und zu bei Oracle vor) dann ist er tiefstes SW-Steinzeit.
Jeder halbwegs vernünftiger Parser wird erkennen ob eine Wildcard am Anfang steht oder nicht.

[himitsu]

Es kommt auch auf die Art des Indizes drauf an.

Einen B-Tree kann man auch teilweise auflösen, also bis zum ersten Wildcard und braucht dann nicht mehr so viel zu durchsuchen.
Ein Hash kann dagegen aber nur komplett aufgelöst benutzt werden.

[Furtbichler]

Zitat:

Zitat von himitsu (Beitrag 1239005)

Es kommt auch auf die Art des Indizes drauf an.
Ein Hash ...

Welches RDBMS verwendet für Indexe den eine Hashtabelle? Ich kenne das nur für schnelle Suchen *ohne* Index.

[himitsu]

Einige DBMS können mehrere Indextypen.

MySQL kann zum BTREE und HASH, je nach verwendeter Speicherengine.


Für reine DupplicateChecks ist eine sortierte Liste der Hashs wohl schneller durchsuchbar, als in einem B-Tree in mehrere Ebenen den passenden Ast zu finden.

[Furtbichler]

Zitat:

Zitat von himitsu (Beitrag 1239016)

...eine sortierte Liste der Hashs...

Bestimmt (imho) keine sortierte Liste von Hashes, denn das müsste auch ein B-Baum sein und wäre auch nicht schneller. Wenn, dann eine Art Hashmap. Da geht das Matchen in O(1), wogegen bei einem B-Baum vom Aufwand O(log n) ist, allerdings mit einer sehr großen Logarithmusbasis: Bei einer Seitengröße von 8k und 4-Byte Key immerhin log zur Basis 2000.

Gut, aber egal: Hash und Sortierung -> geht nicht -> LIKE geht auch nicht.

[dataspider]

Hi,

Firebird sollte hier einen Index verwenden, wenn dieser für das Feld STRASSE definiert ist.

Reinfallen kann man, wenn man hier Parameter verwendet in der Form:

where Strasse like :strasse

und dann den Parameter strasse auf 'Hauptst%' setzt.

Hier kann beim Prepare der Plan nicht ermittelt werden, da nicht klar ist, ob z.B. anstatt

'Hauptsr%' '%Hauptst%' als Wert für den Parameter kommt.


Frank

[EDIT]
Was ich auch schon hatte:
Die Selektivität des Index war irgendwie nicht funktionstüchtig...
Kann man mit
SET STATISTICS INDEX INDEX_NAME
neu berechnen lassen.
[/EDIT]

[Furtbichler]

Zitat:

Zitat von dataspider (Beitrag 1239042)

Reinfallen kann man, wenn man hier Parameter verwendet in der Form:

Code:

where Strasse like :strasse

Das ist aber eine ausgesprochene Schwäche von FB und ein 'fail by design'. Die könnten das Teil auch mit Index kompilieren: Zur Not scant der den Index eben, anstatt den Suchstring anhand der Sortierposition zu finden. Na ja.

[mkinzler]

Das Problem tritt aber auch bei anderen DBMS auf, sogar beim Microsoft SQLServer 2008 R2, dann ist dieser auch schlecht designed.

http://stackoverflow.com/questions/1...erformance-hit