rushmore weniger rasch

14/02/2008 - 13:00 von Olaf Doschke | Report spam
Hallo,

folgender nicht ganz akademischer Fall:

Der voll optimierbare SQL-Select

SELECT SomeID FROM Table1, Table2;
WHERE Table1.Table3ForeignKey = m.tnSomeKey;
AND Table2.Table1ForeignKey= Table1.PrimaryKey;
AND NOT (Table2.Table5ForeignKey = 0);
AND Table2.Table4ForeignKey = 0;
INTO CURSOR curResult

làuft wesentlich lahmer als ein nicht mal voll optimiertes durchscannen
der betreffenden Tabellen:

IF SEEK(m.tnSomeKey,"Table1","Tag on Table3ForeignKey")
SCAN REST FOR Table3ForeignKey = m.tnSomeKey
IF SEEK(Table1.PrimaryKey,"Table2","Tag on Table1ForeignKey")
SCAN REST FOR Table1ForeignKey = Table1.PrimaryKey
IF NOT (Table2.Table5ForeignKey = 0);
AND Table2.Table4ForeignKey = 0

INSERT INTO curMotherbatchescheck VALUES
(th_phasenkomponenten.th_phk_mutteransatz_id)
ENDIF
ENDSCAN
ENDIF
ENDSCAN
ENDIF

Im ersten Fall werden für die Optimierung der WHERE-Bedingungen
NOT (Table2.Table5ForeignKey = 0) und Table2.Table4ForeignKey = 0
Indizes auf diese beiden Felder mitgenutzt. Im Fall der geschachtelten
SCAN-Schleifen nutze ich zur Optimierung lediglich die Indizes
auf die Primàr und Fremdschlüssel, optimiere also quasi nur den
INNER JOIN, der im SQL durch Table2.Table1ForeignKey= Table1.PrimaryKey
in der WHERE-Klausel enthalten ist.

Eine Umstellung auf JOIN bringt da auch keine Besserung.

Ich meine ich habe eine Erklàrung dafür, mich würde interessieren ob
ich damit richtig liege:

In Table2 werden zwei Foreign Keys
Table5ForeignKey und Table2.Table4ForeignKey
verwendet, von denen nur jeweils ein Key genutzt wird.
Der andere ist 0, ich habe hier also eine Art Verzweigung
in der Auswahl, auf was der Datensatz verweist.

Table2.Table4ForeignKey = 0 kommt dabei recht hàufig vor,
Table2.Table5ForeignKey = 0 ist recht selten, die Relation
zu Tabelle4 ist also die üblichere.

Kann es also daran liegen, daß der Index auf Table4ForeignKey
ein sehr unausgewogener BTree ist und daher die Rushmore-
optimierung mit diesem Index langsamer ist, als würde sie wegfallen?

Tatsache ist, daß die Einschrànkung auf
Table3ForeignKey = m.tnSomeKey und auf
Table2.Table1ForeignKey= Table1.PrimaryKey
Das Resultset eh schon auf Größenordnugsmàßig 10
aus Hunderttausenden von Records einschrànkt.

Ich werde mal probieren Tabellen vorab auf bestimmte ORDER
zu setzen und den "störenden" Index mal testweise löschen,
mal sehen was das bringt.

Aber jetzt erst einmal "Mahlzeit".

Tschüß, Olaf.
 

Lesen sie die antworten

#1 Olaf Doschke
14/02/2008 - 17:09 | Warnen spam
Äh.
INSERT INTO curMotherbatchescheck VALUES
(th_phasenkomponenten.th_phk_mutteransatz_id)



Konsequenter Weise müßte das
INSERT INTO curResult VALUES (Table2.SomeID)
sein, ist aber nicht so wichtig daran.

Vorab ORDER zu setzen bringt nix, Die Reihenfolge der
Wherebedingungen austauschen ebenso nichts.

Den Index-Tag auf das Feld zu löschen, was so unausgewogen
gefüllt ist, half aber auch nix. Davon hàtte ich mir jetzt versprochen,
daß Rushmore die Optimierung aufgibt und das Restergebnis
durchscannt, was dann letztlich so schnell wàre wie der
handoptimierte Code. Ist aber nicht so.

Mit FORCE die Tabellenreihenfolge festzulegen halbiert immerhin
die Wartezeit ins ertràgliche.

Tschüß, Olaf.

Ähnliche fragen