Tablica klastrowana jest B-drzewo bez części „sterty” — wiersze są przechowywane bezpośrednio w strukturze B-drzewa indeksu klastrowania (klucz podstawowy). Węzły B-Tree mogą być dzielone lub łączone, więc fizyczna lokalizacja lub wiersze mogą się zmieniać, więc nie możemy mieć prostego „wskaźnika” z indeksu pomocniczego do wierszy, więc indeks pomocniczy musi zawierać kompletną kopię podstawowe pola indeksowe, aby móc wiarygodnie identyfikować wiersze.
Dotyczy to Oracle, MS SQL Server i także dla InnoDB .
Oznacza to, że indeksy pomocnicze w tabelach klastrowych są „grubsze” niż indeksy pomocnicze w tabelach opartych na stercie, które:
- zmniejsza grupowanie danych,
- obniża skuteczność pamięci podręcznej,
- sprawia, że są droższe w utrzymaniu,
- a co najważniejsze, ma wpływ na wydajność zapytań:
- Kwerendy przez indeks pomocniczy może wymagać podwójnego wyszukiwania — jedno wyszukiwanie przez indeks pomocniczy w celu zlokalizowania danych „kluczowych”, a drugie przez indeks podstawowy w celu zlokalizowania samego wiersza (Oracle ma kilka interesujących optymalizacji, aby uniknąć drugiego wyszukiwania, ale InnoDB nie, według mojej wiedzy).
- Z drugiej strony indeks wtórny naturalnie obejmuje więcej pól, dzięki czemu można by całkowicie uniknąć drugiego wyszukiwania tam, gdzie tradycyjny indeks oparty na stercie wymagałby dostępu do tabeli. Jednak ten sam efekt można osiągnąć w indeksie opartym na stercie, po prostu dodając do niego więcej pól.
Pozwolę sobie zacytować Użyj indeksu, Luke! :"Zalety tabel zorganizowanych według indeksu i indeksów klastrowych ograniczają się głównie do tabel, które nie wymagają drugiego indeksu."
Szkoda, ponieważ MySQL nie pozwala na wybór klastrowania niezależnie od silnika pamięci masowej.
