Index bei Like

[Bernhard Geyer]

Zitat von dataspider:

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.

Dann ist hier FB aber sehr mangelhaft implementiert.
In Zeichen von SQL-Injection und Co. sollte alle Abfragen Parametrisiert erfolgen.

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

Kenn dieses Problem beim MS SQL-Server wenn man varchar und nvarchar mischt. Dann wird oft auf Full-Table-Scan umgeschaltet.
Wenn man konsequent nur nvarchar verwendet ist mir das bisher nicht aufgefallen.

[mkinzler]

Zitat:

Dann ist hier FB aber sehr mangelhaft implementiert.
In Zeichen von SQL-Injection und Co. sollte alle Abfragen Parametrisiert erfolgen.

Ist halt nicht von Microsoft!

[dataspider]

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

Hab ich auch lange drüber nachgedacht. Aber das Prepare ist nun mal vor der Zuweisung der Parameter.
Es ist ja wohl so gedacht, dass bei Benutzung der Parameter nur 1 Mal das Prepare erfolgen soll und nicht bei jeder Neuzuweisung eines Parameterwertes.
Die gewünschte Zeitersparnis geht hier natürlich in die Hose.
Mir würde es anders auch gefallen, aber ob das bei anderen DB' s besser gelöst ist, weiß ich nicht.
Ich bin übrigens schon in diese Falle getappt und Thomas Steinmaurer hat das näher erklärt...


Frank

[Dumpfbacke]

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.

Das geht leider nicht oder zumindest mein Firebird 2.5 macht es nicht.

[Namenloser]

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

Vielleicht eine Hashmap und die einzelnen Buckets noch mal sortiert? Dadurch hat man eine bessere Worst-Case-Laufzeit als bei einer „normalen“ Hashmap.

Sowas war vor 1–2 Jahren mal im Gespräch als bei PHP ein Angriff bekannt wurde, bei dem URL-Parameter so präpariert werden konnten, dass es beim Ablegen der Parameter in einem assoziativen Array (was offenbar bei PHP als Hashmap realisiert ist) möglichst viele Kollisionen gab, mit dem Ergebnis dass man den Server sehr leicht lahmlegen konnte. Ich glaube, die PHP-Entwickler haben es am Ende einfach umgangen, indem sie die maximale Anzahl an Parametern standardmäßig limitiert haben.

[Furtbichler]

Zitat von Smut:

Furchti nörgelt halt gerne über Firebird... ich denke, er ärgert sich, dass er selbst nicht mit FB arbeitete

Sag mal, bist Du irgendwie weich in der Birne?

[vagtler]

Zitat von Dumpfbacke:

[...] Das geht leider nicht oder zumindest mein Firebird 2.5 macht es nicht.

Dann muss es aber wirklich an Deinem Firebird liegen. Schau in die Doku und staune.

[hoika]

Hallo,

starting with
sucht genau, also Groß- und Kleinschreibung wird beachtet.

Heiko

[Furtbichler]

Zitat von Namenloser:

Vielleicht eine Hashmap und die einzelnen Buckets noch mal sortiert? Dadurch hat man eine bessere Worst-Case-Laufzeit als bei einer „normalen“ Hashmap.

... Bucketsort wird beim -on-the-fly- 'indizieren' verwendet, um kleinere Datenmengen zu sortieren und dadurch ein besseres Ergebnis zu erzielen. Eine Hashmap hat erst einmal keine Buckets, weil nicht klar ist, wie die Hashmap umgesetzt wurde (open hashing vs. separate chaining). Falls sie als separate chainging umgesetzt wurde, sind die einzelnen 'Buckets' bereits sortiert.

PS: Bei PHP wurde offenbar eine Hashmap mit fester Größe verwendet. Die Problematik kann durch eine dynamische Hashmap vermieden werden. Diese würde ihre Größe ggf. (zu viele Kollisionen) einfach verdoppeln. Da dadurch die Hashfunktion verändert wird, sollten die Angriffe ins Leere laufen.

Aber wir kommen vom Thema ab.

[tsteinmaurer]

Generell sieht die Verwendung eines Index auf einem Feld c1 bei LIKE wie folgt aus:

Code:

select * from t1 where c1 like :c1

=> Kein Index, da parametrisierte Abfrage und zum Zeitpunkt des Prepare der Inhalt des Parameters nicht bekannt ist.

Code:

select * from t1 where c1 like '%Hugo'

=> Kein Index, wenn ein Wildcard als Prefix verwendet wird

Code:

select * from t1 where c1 like 'Hugo'

=> Index

Code:

select * from t1 where c1 like 'Hugo%'

=> Index, bei einem Wildcard als Suffix (wird intern ein STARTING WITH)

Code:

select * from t1 where c1 like upper('Hugo')

=> Index

Code:

select * from t1 where upper(c1) like 'Hugo'

=> Kein Index, da temporäres UPPER auf dem Feld. Abhilfe schafft hier ein Expression-Index, der den UPPER-Inhalt indexiert

Es gibt sicher noch andere Kombinationen ...