SQL: Left Join 30-fach langsamer wie where-Bedingung. Ist das normal?

[juergen]

Hallo zusammen,

nach einigen Tests habe ich festgestellt, dass meine momentane Performancebremse von einer Left-Join-Bedingung kommt.
Wenn ich das Ganze in einer where-Bedingung packe ist es um Faktor 30 schneller.

Nachfolgend meine 2 (rudimentären) SQL-Statements:

SQL-Code:

//Datenmenge ist nicht richtig, da hier die Kundendatensätze NICHT enthalten sind, welche KEINE Ansprechpartner (P.Name) hinterlegt haben. Dafür  aber sehr schnell
Select A.kundenname, P.Name from AdressStamm as A, Kontaktpersonen as P where P.DBAA_RECID = A.Identifikation

//Datenmenge ist richtig, aber extrem langsam (knapp über Faktor 30)
Select A.kundenname, P.Name from AdressStamm as A left JOIN Kontaktpersonen as P on P.DBAA_RECID = A.Identifikation

Da ich hier keinerlei Erfahrung habe und nicht weiß wo ich ansetzen könnte, meine Frage ob das "normal" ist.
Mache ich hier etwas grundlegendes falsch oder woran kann dieser große Performance-Unterschied liegen?

Vielen Dank schon mal für hilfreiche Hinweise!

[alzaimar]

Sind beide Spalten mit einem Index versehen?

[Lemmy]

Hi,

ohne die genaue Datenbank ist das ein bisschen wie Stochern im Nebel...

was mir spontan einfällt:

Wenn bei der ersten Datenmenge 10 Datensätze zurückkommen und bei der zweiten 10.000.000.000 (kannst wegen mir noch ein paar nullen ran machen) dann hätten wir das Problem vermutlich schon eingegrenzt...

Wenn P und A nicht verknüpft sind - was steht dann in A.Identifikation? wenn Da NULL drin ist, könntest Du den oberen Fall mit dem hier ausschließen:

Select A.kundenname, P.Name from AdressStamm as A, Kontaktpersonen as P where P.DBAA_RECID = A.Identifikation OR A.Identifikation IS NULL Normal würde ich so ein Verhalten aber nicht nennen, wobei meine Erfahrung mit Pervasive schon 10 Jahre zurück liegt...

[hoika]

Hallo,

outer joins sind prinzipiell langsamer als inner joins.

Lösung:
1. Lege einen Dummy-Ansprechpartner an (DB-Id=0, Name=NULL)
2. Neue Kunden bekommen diesen AP zugeordnet.

Jetzt noch ein bissel coden
3.
Neuer AP beim Kunden, Dummy löschen, falls vorhanden
AP gelöscht, ist es der letzte, Dummy zuordnen

je nach DB, geht dss auch über Trigger

Jetzt bekommst du per inner join alle Kunden incl. Ansprechpartner.



Heiko

[juergen]

puhh, so schnelle Antworten.

@ alzaimar,
Ja, Index ist vorhanden.

@ Lemmy,
Der Unterschied in den beiden Datenmenge beträgt ca. 450 Datensätze, also vernachlässigbar.
A.Identifikation ist die eindeutige Rec-Id der Tabelle und kann nicht NULL sein.

Ich glaube nun fast, dass Pervasive an der Stelle Probleme hat. Ich gebe zum Testen das SQL-Statement direkt im SQL Manger von Pervasive ein, also kein Delphi oder anderes Störquellen.
Falls Pervasive Problem haben sollte mit Join's:
Gibt es hierzu vllt. Alternativen? Auch ein INNER Join ist sehr langsam...


//Edit roter Kasten
@ hoika
Punkt 1: Sowas ähnliches hatte ich mir auch schon überlegt, einfach einen leeren Datensatz bei Neuanlage mit anlegen, dann könnte ich ja auch die where-Bedingung anwenden. Ich würde sowas aber ungern so umsetzen.

Schon mal Danke für Eure Antworten!

[Jumpy]

Zitat von Lemmy:

Hi,
Select A.kundenname, P.Name from AdressStamm as A, Kontaktpersonen as P where P.DBAA_RECID = A.Identifikation OR A.Identifikation IS NULL

Da wir gerade Subsecelct in der Schule haben 'ne Abwandlung hiervon, wobei ich nicht weiß, ob Subselects nicht auch langsam sind (und ob das da unten so richtig ist - wie gesagt gerade erst gelernt):

Select A.kundenname, P.Name from AdressStamm as A, Kontaktpersonen as P where P.DBAA_RECID = A.Identifikation OR A.Identifikation NOT IN (Select Distinct DBAA_RECID From Kontaktpersonen)

[jobo]

Sind wirklich beide Indices vorhanden?
Was ist die normale Laufzeit? Faktor 30 auf 10 Millisekunden fänd ich nicht so schlimm.
Was sind die absoluten Datenmengen?

Falls die Gesamtmengen groß sind und mangels Ahnung von Pervasive:
Wie sieht es da mit einem Optimizer aus? Gibt es sowas wie Statistiken? Wenn ja, sind die aktuell?

Unabhängig vom der Datenmenge, Index evtl. neu aufbauen.

[generic]

Schau dir mal die Ausführungspläne der SQLs an.

[juergen]

Hallo zusammen,

die Frage von alzaimar im Post #2 hätte ich besser lesen müssen.
Nach dem für mich deutlicheren Hinweis von jobo im Post #7 muss ich sagen:
- es gibt nur in der Tabelle Kontaktpersonen einen Index auf die Rec-ID der Tabelle AdressStamm.

Wie gesagt ich habe da nicht so die Ahnung:
- muss es denn in der Tabelle AdressStamm auch noch einen Index auf die Rec-ID der Tabelle Kontaktpersonen geben?

Letztlich beträgt die Datenmenge etwas über 14.000 Datensätze, also nicht so viel.
Das Ausführen der SQL-Statements mit der where-Bedingung dauert 5 Sekunden, mit der Left Join-Bedingung 2:33 (Min:sek).

Sowas wie Optimizer oder SQL Ausführungspläne kenne ich für Pervasive nicht.

Schon mal Danke für Eure Hilfe!

[alzaimar]

Nun ja, 14k x 14k wäre dann aber fett.

Also: Die DB muss für jede Zeile der 1.Tabelle die passenden Einträge in der 2.Tabelle suchen.

Mit Index geht das EinsFixDrei, ohne sucht die DB sequentiell in der 2.Tabelle. Von vorne nach hinten. Na ja, manchmal nicht ganz, aber prinzipiell schon.

Du musst/solltest einen Index am Besten auf beide Spalten der JOIN-Verknüpfung legen.