Performanceproblem parambyname und sql like

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

[Morphie]

Wie wir eben gelernt haben, tritt das nur bei Parametern auf. Sonst ist Firebird sehr wohl in der Lage einen Index bei Like zu verwenden.
Das Problem bei Parametern ist, dass Firebird beim Prepare ggf. noch keine Parameter kennt. Erst wenn ein Parameter gesendet wird, KÖNNTE Firebird darauf reagieren. Dazu müsste Firebird den Parameter aber auch analysieren...
Und dann ist es auch möglich, weitere Parameter abzuschicken, die das selbe Prepared-Statement verwenden. Das Prepare müsste also erneut durchgeführt werden. (Und somit den Ausführungsplan erneut aufbauen) Das würde die Sache mit dem Prepared-Statements aber wieder sinnlos machen...

Wie ich schon schrieb: Das ginge in diesem Fall zwar sicher schneller als der FullTableScan, aber ggf. ist es in anderen Szenarien nicht erwünscht...

[mkinzler]

Zitat:

Das Problem bei Parametern ist, dass Firebird beim Prepare ggf. noch keine Parameter kennt.

Die Parameter schon, aber deren Inhalt nicht.

[Morphie]

Meine ich doch

[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

[Union]

Sehr interessantes Thema. Ich habe aber noch eine Anmerkung zu der Testroutine: Da die Daten in der ersten Abfrage ja im Cache landen, hat man nicht mehr die gleichen Bedingungen bei den beiden weiteren Tests. Für eine exakte Messung müsste man den Service jeweils neu starten.

[stalkingwolf]

Ich habe die Routinen bei mir auch einmal umgedreht und 1 vor 2 gesetzt. Das Resultat war immer identisch. Dabei lieferte "starting with" immer die beste Performance.

Aber ja sonst hast du recht. Allerdings ist bei meiner Testumgebung mit so vielen Daten es irrelevant