Eine geclusterte Tabelle ist ein B-Baum ohne "Heap"-Teil - Zeilen werden direkt in der B-Baum-Struktur des Clustering-Index (Primärschlüssel) gespeichert. Knoten des B-Baums können geteilt oder zusammengeführt werden, sodass sich die physische Position oder Zeilen ändern können, sodass wir keinen einfachen „Zeiger“ von einem Sekundärindex auf die Zeilen haben können, sodass der Sekundärindex eine vollständige Kopie von enthalten muss die primären Indexfelder, um Zeilen zuverlässig identifizieren zu können.
Dies gilt für Oracle, MS SQL Server und gilt auch für InnoDB .
Das bedeutet, dass Sekundärindizes in geclusterten Tabellen "dicker" sind als Sekundärindizes in Heap-basierten Tabellen, die:
- verringert das Daten-Clustering,
- verringert die Effektivität des Caches,
- macht sie teurer in der Wartung,
- und was am wichtigsten ist, hat Auswirkungen auf die Abfrageleistung:
- Das Abfragen über einen sekundären Index erfordert möglicherweise eine doppelte Suche - eine Suche über den sekundären Index, um die "Schlüssel"-Daten zu finden, und eine über den primären, um die Zeile selbst zu finden (Oracle hat einige interessante Optimierungen, um die zweite Suche zu vermeiden, aber InnoDB tut dies meines Wissens nicht).
- Andererseits deckt der Sekundärindex natürlich ab mehr Felder, sodass die zweite Suche insgesamt vermieden werden könnte, wo ein traditioneller Heap-basierter Index einen Tabellenzugriff erfordern würde. Derselbe Effekt kann jedoch auch im Heap-basierten Index erzielt werden, indem einfach weitere Felder hinzugefügt werden.
Lassen Sie mich Verwenden Sie den Index, Luke! :"Die Vorteile von indexorganisierten Tabellen und Clustered-Indizes beschränken sich meist auf Tabellen, die keinen zweiten Index benötigen."
Was schade ist, da MySQL Sie das Clustering nicht unabhängig von der Speicher-Engine wählen lässt.
