Sortieren und Gruppieren

Sortieroperationen sind sehr Ressourcen-intensiv. Zum einen benötigen sie verhältnismäßig viel CPU-Zeit. Das Hauptproblem ist aber, dass das Ergebnis zwischengespeichert werden muss. Schließlich müssen erst alle Zeilen gelesen werden, bevor die Erste ausgegeben werden kann. Eine Sortieroperation kann also nicht „am Fließband“ (pipelined) ausgeführt werden. Das kann bei großen Datenmengen zum Problem werden.

Ein Index stellt eine sortierte Kopie der indizierten Daten zur Verfügung. Dieses Funktionsprinzip wurde bereits in Kapitel 1 beschrieben. Man könnte auch sagen, dass ein Index die Daten vorsortiert abspeichert. Und zwar so, als würde man die Indexdefinition in eine order by-Klausel übernehmen. Es ist also naheliegend, dass man Indizes auch für order by-Klauseln verwenden kann.

Doch gerade bei großen Datenmengen kann ein INDEX RANGE SCAN ebenfalls ineffizient sein. Das kann den Vorteil, dass die explizite Sortierung ent­fällt, zunichtemachen. Ein Full-Table-Scan mit expliziter Sortierung kann dann immer noch besser sein. Es liegt also wieder am Optimizer, die verschiedenen Ausführungspläne zu bewerten und den besten auszu­wählen.

Eine indizierte order by-Ausführung spart aber nicht nur den Sortierauf­wand, sondern kann die ersten Ergebnisse bereits liefern, bevor die Ein­gangsdaten vollständig gelesen wurden. Das order by wird also „am Fließband“ ausgeführt (pipelined execution). Kapitel 7, „Teilergebnisse“, zeigt, wie man ein „pipelined order by“ nutzen kann, um Blätterabfragen effizient umzusetzen. Dadurch wird das pipelined order by so mächtig, dass ich es als die „dritte Macht der Indizierung“ bezeichne.

Dieses Kapitel zeigt, wie man einen Index für ein pipelined order by nutzt. Dabei sind insbesondere die Wechselwirkungen mit der where-Klausel, aber auch ASC- und DESC-Spezifikationen, zu beachten. Abschließend wird noch erklärt, wie man diese Methoden auf group by-Klauseln anwendet.