Index bei Like

[Dumpfbacke]

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

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 von 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.

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 von himitsu:

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 von himitsu:

...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 von dataspider:

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