Tip: Performance Tuning

[Holger Deubel]

Hallo zusammen,

seit langem auch mal wieder im Forum :-) und gleich ein Tip für alle Interbase'ler:

Wie sich so eben bei Versuchen ein Query schneller zu machen herausstellte bringt folgende Variante einer where-Bedingung immense Performancezuwächse:

select artikel.id, artikel.bezeichnung, hersteller.bezeichnung
from artikel
inner join hersteller on artikel.hersteller_id = hersteller.id
where upper(hersteller.bezeichnung) like "%ORLA%"
and not (artikel.hersteller_id = 0)

die vorige und für mich viel logischere variante war:

select artikel.id, artikel.bezeichnung, hersteller.bezeichnung
from artikel
inner join hersteller on artikel.hersteller_id = hersteller.id
where upper(hersteller.bezeichnung) like "%ORLA%"
and artikel.hersteller_id > 0

der join ging noch über 2 weitere tabellen, die ich der einfachheit halber hier weggelassen habe. wer id's benutzt wird sich über einen select, der 50 MILLISEKUNDEN gegenüber vorher 30 SEKUNDEN freuen

viele grüße
holger

[Najib Amaioua]

Da geb ich dir vollkommen recht mit der Performance Verbesserung...
aber:

was passiert wenn ich auch keine negativen ids haben moechte?

( X > 0) => WerteBereich 1 -> unendlich...

not (X = 0) => WerteBereich (-unendlich) <- (-1)
1 -> (unendlich

[Holger Deubel]

hallo najib,

ganz einfach:

...and not (artikel.hersteller_id <= 0)

grüße,
holge

[Najib Amaioua]

Und weisst du auch den Grund warum "not ( X <= 0 )" schneller ist als "X > 0" arithmetisch ist das doch das gleiche..

[hwoess]

Hallo Holger,

Performance kann man nie genug haben - habe das also gleich auch mal bei meinen Daten ausprobiert. Allerdings ohne Erfolg. Beim ersten Aufruf ist ein Statement immer um Welten langsamer als wenn ich es dann unverändert ein zweites mal aufrufe, da dann das Prepare wegfällt und eigentlich schon vieles aus dem Cache kommt. Hast du dieses Unterschiede auch, wenn du das mal umgekehrt probierst, also erst mal das schnelle Statement exekutierst, dieses dann auf die langsame Version änderst und diese ausführst?<br>
Oder hast du das zu bald gepostet - der 1. April kommt erst :-))

bye,<br>
Helmu

[Holger Deubel]

Hallo Helmut,

nein, ich habe erst das eine Statement ausgeführt, die Verbinung gekappt und dann das andere völlig unabhängig ausgeführt. Das ebenfalls auf mehreren Rechnern ausprobiert, auch in umgekehrter Reihenfolge. Es war immer in der von mir beschriebenen Art schneller.

Ich denke, es liegt an der Menge zu inkludierender bzw. exkludierender Datensätze, dass mal das eine, mal das andere schneller ist!? Ist aber nur eine Vermutung... Weiß es jemand?

Grüße,
Holge

[Carsten Haberland]

<b>Hallo zusammen,</b><br><br>
ich habe mal beide SQL-Statements bei mir ausprobiert.<ul>
<li><i>select * from Muster where ID > 0;</i></li>
<li><i>select * from Muster where not (ID = 0);</i></li>
</ul>
Bei mir ist das erste Statement schneller und über einen PlanAnalyser sieht es auch sauberer aus.<br><br>
Ich vermute aber mal, da in meinem Fall <i>ID</i> ein <i>primary key</i> (alternativ auch <i>unique</i>) ist, läuft die erste Anweisung besser.<br><br>
MfG,<br>
Carsten<br&gt

[Holger Deubel]

Hallo Carsten,

in dem Fall ist auch bei mir das erste schneller, nur beim join mehrer Tabellen ist der zweite Fall besser...

Grüße
Holge

[Carsten Haberland]

<b>Hallo Holger,</b><br><br>
bei <i>join</i>s über mehrere Tabellen, ist auch die erste Variante bei mir die schnellste. Dabei muss ich aber bemerken, dass die <i>ID</i> in der <i>where</i>-Klausel der <i>primary key</i> der Haupttabelle des <i>Join</i>s ist.<br><br>
Ich denke mal, je nachdem, wie die <i>ID</i>s indiziert sind, läuft mal die eine Variante besser und mal die andere.<br><br>
MfG,<br>
Carsten<br&gt