Performanceproblem parambyname und sql like

[Hansa]

Das "like" hebelt alle Indexe aus.

[Furtbichler]

Zitat von Hansa:

Das "like" hebelt alle Indexe aus.

Dann wäre FB aber ziemlich blöd.

[Morphie]

Aber in welcher Unit findet denn diese mysteriöse "Optimierung" statt?
btw: Firebird 2.5 stimmt?
denn: http://www.firebirdfaq.org/faq308/

[mkinzler]

Die Optimierung hat mit dem Zeitpunkt der Planbildung zu tun. Beim Absetzen der Abfrage ohne Parameter ist bekannt, das das LIKE durch ein STARTING ersetzt werden kann. Bei der Verwendung von Parametern nicht, das ja der/die Wildcard(s) im Parameter stecken.

[stalkingwolf]

klingt plausible.
Wir konnten es auch nur bei like feststellen. Bei key = :key gab es keine Performanceprobleme. Man muss also nicht alle Programm ändern.

Wegen der 2.5 FB Frage. Laut Whatsnew v2.5.1

[Morphie]

Stimmt... Wobei es dann Verbesserungspotential bei Firebird gibt.
Klar, wenn die Abfrage Parameter verwendet, kann Firebird nicht wissen, ob der Index möglicherweise doch benutzt werden kann (im Falle von "Text%")
Aber spätestens wenn der Parameter übergeben wird, weiß Firebird doch was zutun ist.

Natürlich müsste Firebird dafür den Ausführungsplan neu aufbauen, aber das wäre mit Sicherheit schneller als einen Fulltablescan zu fahren.
Wird der Parameter ersetzt, muss der Ausführungsplan ebenfalls neu aufgebaut werden.

[mkinzler]

Man könnte auch das Like durch STARTING ersetzten, dann klappt es auch mit dem Parameter

[Hansa]

das wäre ja dann so was : "%Suche". Jo, könnte besser sein.
Problem ist jedenfalls das LIKE.

[DeddyH]

Nee, sowas wäre das nicht, das % gehört ans Ende. Mich verwundert, dass FB nicht in der Lage sein soll, zu erkennen, ob es bei LIKE einen Index benutzen kann oder nicht. Bei Wildcards am Ende ließe sich ein ggf. vorhandender Index ja sehr wohl benutzen.

[hstreicher]

Zitat von Morphie:

Stimmt... Wobei es dann Verbesserungspotential bei Firebird gibt.
Klar, wenn die Abfrage Parameter verwendet, kann Firebird nicht wissen, ob der Index möglicherweise doch benutzt werden kann (im Falle von "Text%")
Aber spätestens wenn der Parameter übergeben wird, weiß Firebird doch was zutun ist.

Natürlich müsste Firebird dafür den Ausführungsplan neu aufbauen, aber das wäre mit Sicherheit schneller als einen Fulltablescan zu fahren.
Wird der Parameter ersetzt, muss der Ausführungsplan ebenfalls neu aufgebaut werden.

Das wiederspricht aber dem Konzept des Prepared Queries, das ja _gerade_ durch den vorbereiteten Plan (meist) schneller ist
also einfach die Prepared Queries so lassen , und im Zweifellsfall das normale Query verwenden
man kann nicht erwarten dass jedes Werkzeug für jede Aufgabe optimal ist.

Das heisst dass für uns Programmierer noch etwas Arbeit übrig bleibt , und uns die Computer nicht so schnell ersetzen werden