Full Table Scan schneller als Index Scan

[TS]

Hello,

Dann wäre es doch sinnvoller, zunächst mal den Index unfragmentiert zu halten, bzw. im Cache.

Der Index ist aufgrund seiner Datenstruktur „fragmentiert.“ Um in einem Baum zu suchen musst du ja innerhalb dieses Baumes den Knoten folgen.

Selbstverständlich. Das war dumm ausgedrückt.

Die einzelnen Blätter des Index-Baums sollten unfragmentiert vorliegen. Das versucht man ja, indem man die Blattgröße mit der Blocksize im Dateisystem harmonisiert, bzw. die Blätter/Blöcke mit genügend "Luft" ausstattet.

Aber z. B. zehn Zugriffe über den Index würde schon eine erhebliche Indextiefe (Spezifität) bedeuten, während 10 Zugriffe auf die Daten (die müssen ja totzdem die Buffersize beachten) vielleicht erst 0.1% der Datei erfasst haben.

Vielleicht hänge ich, geprägt von Novell und Elevator Seeking und ähnlichen Techniken noch zu dicht an der Hardware, oder aber Ihr nicht dicht genug?

Und in meiner Vorstellung kann ein mit z. B. 128 GB RAM ausgestatter Host die auch nicht "mal eben" komplett für einen einzigen DB-Filezugriff zur Verfügung stellen, sondern muss seine Gunst verteilen. Und da gäbe es als Flaschenhals auch immer noch die maximale Datentransferrate zwischen HDD und RAM. In z. B. 10x8ms (für die vermuteten Indexzugriffe) wird man kaum die komplette Datei in den RAM bewegen können.

Nach meinem Verständnis hinkt das immer noch. Da muss es erlaubt sein, nach der Kompexität der Abfrage und näheren Details zur Index- und zur Spaltendefinition zu fragen :-O

Liebe Grüße
Tom S.