Клъстерираната таблица е B-дърво без "хийп" част - редовете се съхраняват директно в структурата на B-дървото на индекса за клъстериране (първичен ключ). Възлите на B-дървото могат да бъдат разделени или обединени, така че физическото местоположение или редовете могат да се променят, така че не можем да имаме прост "указател" от вторичен индекс към редовете, така че вторичният индекс трябва да включва пълно копие на първичните индексни полета, за да могат надеждно да идентифицират редове.
Това е вярно за Oracle, MS SQL Server и е вярно и за InnoDB .
Което означава, че вторичните индекси в клъстерираните таблици са "по-дебели" от вторичните индекси в базирани на хеп таблици, което:
- намалява групирането на данни,
- намалява ефективността на кеша,
- оскъпява поддръжката им,
- и най-важното, има последствия върху ефективността на заявката:
- Запитването през вторичен индекс може да изисква двойно търсене – едно търсене през вторичния индекс за намиране на „ключовите“ данни и едно през първичния, за намиране на самия ред (Oracle има някои интересни оптимизации за избягване на второто търсене, но InnoDB не го прави, доколкото ми е известно).
- От друга страна, вторичният индекс естествено покрива повече полета, така че второто търсене може да бъде избегнато напълно, когато традиционният индекс, базиран на хеп, изисква достъп до таблица. Същият ефект обаче може да се постигне в индекса, базиран на heap, чрез просто добавяне на още полета към него.
Позволете ми да цитирам Използвайте индекса, Люк! :„Предимствата на организираните от индекси таблици и клъстерираните индекси са предимно ограничени до таблици, които не се нуждаят от втори индекс.“
Което е срамота, тъй като MySQL не ви позволява да избирате клъстерирането независимо от механизма за съхранение.
