Performancevorteil mit Constraints?

[lorenzen]

Unsere SQL-Tabellen haben Primärschlüssel und werden häufig mit Verknüpfungs-formulierungen (select.. join on ..)abge-fragt.
Würde es Performance Verbesserungen geben, wenn die entsprechenden Tabellen sowohl mit Primary-, als auch Foreignkeys als Con-straints ausgestattet würden?
Anders gefragt: Würde der Optimizer dann bei der Verknüpfungsabfrage auf bestehende Adressen zugreifen können und somit das Er-gebnis schneller liefern?

[Fuerchau]

Eindeutig Ja.

Der Optimizer versucht anhand vorhandener Zugriffspfade zu optimieren.
Häufig benutzte Abfragen sollten sie mittels CREATE VIEW bereits vordefinieren, so dass nicht permanent dynamische Zugriffspfade erstellt werden müssen.

Wichtig ist ggf. die Verwendung von INNER JOIN, da diese Zugriffswege auch permanent angelegt werden können. LEFT JOIN oder EXCEPTION JOIN (auch OUTER JOIN) sind leider immer dynamisch. Für die on (...)-Beziehung ist es von großem Vorteil, Schlüssel zu haben.
Auch über, in der WHERE- sowie GROUP-Klausel, verwendete Felder sollten Schlüssel vorhanden sein, damit nicht immer neu sortiert werden muss.

[lorenzen]

Danke für die umfangreiche Antwort.
Ich bin mir jedoch nicht ganz sicher ob ich es richtig verstanden habe, deshalb noch einmal kurz um sicher zu gehen:

Wir haben jedes SQL-Statement analysiert (Visual Explain, STRDBG) und entsprechend alle Indices und auch Views generiert. Wir lassen auch regelmäßig SQL Leistungsanalysen laufen, so das wir hoffen, über alle nötigen Zugriffspfade zu verfügen. Die Frage bezieht sich vielmehr darauf, ob wir neben dem Primärschlüssel, allen Indices und Views, pro Tabelle auch eine referentielle Integritätsbedingungen in Form eines Foreignkeys anlegen sollen um damit einen Performancevorteil zu erhalten?

[rmittag]

machen wir hier weiter :

<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>... neben dem Primärschlüssel, allen Indices und Views ...[/quote]
ein Foreign Key Constraint erzeugt auch einen Zugriffsweg. Wenn der noch nicht da war, dann kann es eventuell etwas bringen. Wenn der Zugriffsweg schon bei allen Indices ... dabei ist, natürlich nicht.
Meine Erfahrung ist : wenn in dem Verfahren STRDBG -> DSPJOBLOG keine Probleme berichtet werden, dann alles eher so lassen.
Dann gilt der alte Satz : die Performance ist dann schlecht, wenn sich die Anwender beschweren.

Gruß Rolf

[Robi]

Hast du die Indices als EVI angelegt ?
Die sind kleiner und schneller bei ... where abfragen

CREATE encoded vector index ...

Robi

[lorenzen]

Dank an alle Beteiligten.
Da die Zugriffspfade bereits über Indices abgedeckt sind, folge ich der Meinung von Rolf und werde keine Foreignkeys zusätzlich anlegen.
Zu den EVI's: Der Einsatz davon ist nur unter bestimmten Voraussetzungen sinnvoll, das sagt zumindest die Hilfe unter Visual Explain und auch die Infos aus dem Iseries Network. Dennoch Danke für den Hinweis, ich werde in Einzelfällen sicher davon Gebrauch machen, muss mich aber erst eingehender damit beschäftigen.

Gruß Sven Lorenzen