SQL-Tuning mit coalesce(...) ?

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo zusammen,

ich habe in den letzten Tagen versucht, ein paar SQL-Statements ein bisschen flotter zu machen und habe mit folgendem Tipp irgendwie unglaubwürde Erfolge erzielt, die ich noch nicht ganz verstehe.
(Umgebung ist DB2 V8)

Ein Statement der Art:

select \* from tab1
join tab2 on tab1.key = tab2.key
where tab2.attr = 1;

wurde zu

select \* from tab1
join (select \* from tab2 where coalesce(attr, 0) = 1) tab2 on 
 tab1.key = tab2.key;

Wenn ich mich jetzt nicht vertippt habe, sollten diese Statements die selbe Ergebnismenge beschreiben, dummerweise ist das zweite spürbar schneller - ein Explain ergab einen Vorteil von ~28% (allerdings im deutlich umfangreicheren Original-Statement, dass ich jetzt vielleicht um wichtige Details reduziert habe…?).

Hab ich mich irgendwo verguckt?
Kann es was mit der Selektivität des Schlüssels oder des Kennzeichens zu tun haben?
Ist coalesce(…) für den Optimizer toller?
Ist es einfach nur Zufall und Einbildung?

Ich bin wirklich neugierig!

Über jede Antwort freue ich mich, danke im Voraus,
Till

#2

Query 1

select \* 
 from tab1
 join tab2 
 on tab1.key = tab2.key
 where tab2.attr = 1;

Query 2

select \* 
 from tab1
 join (select \* 
 from tab2 
 where coalesce(attr, 0) = 1) tab2 
 on tab1.key = tab2.key;

Hallo Till,

nach der Beschreibung aus der Dokumentation ist coalesce identisch mit der Oracle-Funktion nvl (wenn Wert1 gleich NULL dann nimm Wert2). Der Performancevorteil kann deshalb auch daran liegen, wieviele Werte in Tabelle tab2 das Attribut attr auf NULL stehen hat. Dann wäre die Zwischentabelle im zweiten Statement erheblich kleiner und damit die Anzahl der zubewegenden Blöcke zum Join zwischen den beiden Tabellen erheblich kleiner.

Aber ohne mehr Hintergrundinformationen ist dies aber nur Glaskugelraten (und die steht immer noch im Büro). Hast Du geprüft ob ein Index auf die key-Attribute der beiden Tabellen sind? Bei Tabelle 2 würde sich auch ein Index (Key, attr) anbieten (reiner Indexzugriff).

MfG

Georg V.

#3

Hallo Georg,
vielen Dank für Deine Antwort.

[…]Dann wäre die Zwischentabelle im zweiten
Statement erheblich kleiner und damit die Anzahl der
zubewegenden Blöcke zum Join zwischen den beiden Tabellen
erheblich kleiner.

Das ist nachvollziehbar. Ich muss mal gucken, ob in verschiedenen Statements immer die gleichen Verhältnisse der Mengen zueinander auftreten…

Aber ohne mehr Hintergrundinformationen ist dies aber nur
Glaskugelraten (und die steht immer noch im Büro). Hast Du
geprüft ob ein Index auf die key-Attribute der beiden Tabellen
sind? Bei Tabelle 2 würde sich auch ein Index (Key, attr)
anbieten (reiner Indexzugriff).

Key-Indizes sind da, den zweiten Index muss ich am Montag mal suchen :smile:

Tschöö
Till