sayso Geschrieben 18. Dezember 2006 Teilen Geschrieben 18. Dezember 2006 Hallo Kollegen, ich habe mir heute eine Frage bezüglich Indezes gestellt. Und zwar folgendes Szenario: Ich habe eine Tabelle TAB_USER. Diese hat folgende Felder USER_ID int NNAME varchar(50) VNAME varchar(50) STR varchar(50) PLZ int ORT varchar(50) TEL varchar(50) Nun ist USER_ID mein Primärschlüßel. Lege ich einen Index über diesen somit ist der Zugriff über eine WHERE Klausel mit USER_ID schneller als wenn ich keinen Index habe - z.B.: Select * from TAB_USER where USER_ID = 57; Aber warum ist das so? Ich habe auch schon versucht, die Eigenschaften von den verschiedenen Index-Typen zu verstehen (B-Tree, Bitmap,etc.) aber bis auf IO-Tables habe ich nicht wirklich verstanden warum es schneller geht. Bei IO-Tables stehen die Daten mit im Index... Das es so ist, will hier wohl keiner abstreiten. Aber warum ist ein Zugriff über den Index schneller? Wie verknüpft Oracle den Indextreffer mit den Daten in den Tabellen? Das Thema ist vielleicht etwas abstrakt, aber mich interessiert trotzdem wie das "intern" funktioniert. Wäre super wenn mir das jemand erklären könnte oder evtl. Links postet in denen es gut beschrieben ist. Danke Gruß sayso Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
derJan Geschrieben 18. Dezember 2006 Teilen Geschrieben 18. Dezember 2006 Na wenn du dir z.B. die Idee hinter Balaced Trees anschaust wirst du feststellen, dass du mit einigen wenigen Entscheidungen schon einen Großteil der Zeilen ausschließen kannst. Wenn z.B. auf der Stammebene A-M und N-Z hast und dein gesuchtes Wort mit D anfängt hast du damit schon etwa die hälfte aller Zeilen ausgeschlossen (von gleichmäßiger Verteilung ausgegangen) nach der zweiten Entscheidung auf der Zwischenebene hast du die in Frage kommenden Zeilen schon auf 1/4 reduziert und so weiter... Ob jetzt ganz am Schluss die Daten direkt in den Seiten des B-Tree stehen oder dort ein Verweis auf den Ort der Dateien ist nicht mehr der große Unterschied... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
sayso Geschrieben 18. Dezember 2006 Autor Teilen Geschrieben 18. Dezember 2006 Ob jetzt ganz am Schluss die Daten direkt in den Seiten des B-Tree stehen oder dort ein Verweis auf den Ort der Dateien ist nicht mehr der große Unterschied... hmm aber warum ist dann ein IOT schneller als eine Tabelle mit Index? Die entscheidende Frage ist doch: Wie sieht so ein Verweis aus (vom Index zu den Daten) ? So einen Tree könnte man doch auch in der Tabelle aufbauen (vorausgesetzt wie in meinen Beispiel) der Primärschlüssel ist ein auto_increment. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
sayso Geschrieben 18. Dezember 2006 Autor Teilen Geschrieben 18. Dezember 2006 Habe gerade ein richtig gutes Dokument gefunden: http://www.geocities.com/kensanata/tuning/performa.pdf Dort werden eigentlich alle meine Fragen beantwortet Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Crush Geschrieben 19. Dezember 2006 Teilen Geschrieben 19. Dezember 2006 Also der SQL-Index kann sich nach Wikipedia überall unterschiedlich verhalten. Die Handhabung ist herstellerspezifisch. Also kann da jeder sein eigenes Süppchen intern brauen. Bei Oracle ist es, wie es in Deinem Link steht, wohl vor allem die Read/Write-Blockgröße. Das bedeutet, daß die Größe des Blocks möglichst ein Vielfaches des Filesystems der Platte entsprechen sollte, damit die Zugriffszeiten optimiert werden. Zusätzlich spielt aber sicher auch die betriebssysteminterne Caching-Routine noch dazu. Ich denke, mit Experimentieren könnte man da am weitesten kommen, wo das Optimum in etwa liegt. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.