Der SQL Translator verbessert die Abfrageleistung, indem optimierter Code erzeugt wird, der es der zu Grunde liegenden Abruf-Engine ermöglicht, auf die ausgewählten Datensätze direkt zuzugreifen, ohne alle Segmentinstanzen zu scannen.
Weitere Informationen über Indexoptimierung und optimierte Join-Anweisungen finden Sie in der Server-Dokumentation für Ihre Plattform.
x
Der SQL Translator akzeptiert Joins in der SQL-Syntax. SQL-Sprache-Joins haben keine implizierte Richtung. Die Konzepte der Host- und Querverweisdateien existieren in SQL nicht.
Der SQL Translator analysiert jeden Join, um effiziente Implementation zu identifizieren. Zunächst weist er den Kandidaten-Joins in der Abfrage Kosten zu:
- Cost = 1 für einen Equijoin mit einem Feld, das verwendet werden kann als ein Querverweisfeldgemäß der FOCUS-Join-Regeln. Dies ist üblich bei Abfragen mit relationalen Tabellenmit Equijoin-Prädikaten in der WHERE-Klausel.
- Cost = 16 für einen Equijoin mit einem Feld, das nicht verwendet werden kann als ein Querverweisfeldgemäß der FOCUS-Join-Regeln.
- Cost = 256 für einen Nicht-Equijoin oder ein uneingeschränktes kartesisches Produkt.
Der Translator verwendet diese Kosten dann, um eine Join-Struktur für die Abfrage zu erstellen. Die Reihenfolge der Tabellen in der FROM-Klausel der Abfrage wirkt sich auf die ersten zwei Phasen der Join-Analyse aus:
- Wenn es cost=1-Joins aus der ersten Tabelle gibt, auf die in der Klausel FROM auf die zweite Tabelle verwiesen wird, von der zweiten Tabelle auf die dritte usw., verbindet der Translator die Tabellen in der Reihenfolge, die in der Anfrage angegeben wurde. Falls nicht, wird mit der Phase 2 fortgefahren.
- Wenn die Phase 1 keine zulässig Join-Struktur erzeugt, versucht der Translator, eine Join-Struktur zu erstellen, ohne eine Tabelle mit einer Tabelle zu verbinden, die ihr in der FROM-Klausel vorhergeht. Daher macht diese Phase immer die erste in der Anfrage verwiesene Tabelle zur Host-Tabelle. Wenn es keinen cost=1-Join zwischen zwei Tabellen gibt, oder wenn Sie die Tabellenreihenfolge ändern müssen, um einen zu verwenden, bricht der Translator die Phase 2 ab und implementiert die Phase 3.
- Der Translator erzeugt die Join-Struktur zuerst von den Joins mit den niedrigsten Kosten, und dann wenn nötig von den teureren Joins. Dieser Sortiervorgang kann die Reihenfolge ändern, in der Tabellen verbunden werden. Die Effizienz des Joins, den diese Prozedur erzeugt, hängt von der relativen Größe der Tabellen ab, die verbunden werden.
Wenn die Analyse dazu führt, dass mit einer Tabelle verbunden wird, die aufgrund von FOCUS-Regeln nicht als Querverweisdatei dienen kann (weil beispielsweise ein Index felt), erzeugt der Translator Code, um eine indizierte HOLD-Datei zu erstellen, und implementiert den Join mit dieser Datei. Die HOLD-Datei ist jedoch nicht Teil der Analyse der Join-Reihenfolge.