Nevím o vnitřnostech Microsoft SQL Server, ale mohu odpovědět za MySQL, které jste označili pro svůj dotaz. Podrobnosti se mohou u jiných implementací lišit.
O1. Správně, pro seskupený index není potřeba žádné místo navíc.
Co se stane, když zrušíte seskupený index? Engine InnoDB MySQL vždy používá primární klíč (nebo první nenulový jedinečný klíč) jako seskupený index. Pokud definujete tabulku bez primárního klíče nebo zrušíte primární klíč existující tabulky, InnoDB generuje interní umělý klíč pro seskupený index . Tento interní klíč nemá žádný logický sloupec, který by na něj odkazoval.
Q2. Pořadí řádků vrácených dotazem, který používá index bez klastrů, není zaručeno. V praxi je to pořadí, ve kterém byly řádky přístupné. Pokud potřebujete, aby byly řádky vráceny v určitém pořadí, měli byste použít ORDER BY ve vašem dotazu. Pokud optimalizátor dokáže odvodit, že požadované pořadí je stejné jako pořadí, ve kterém bude přistupovat k řádkům (pořadí indexu, ať už podle seskupeného nebo neseskupeného indexu), může krok řazení přeskočit.
Q3. Neklastrovaný index InnoDB nemá ukazatel na odpovídající řádek na listu indexu, má hodnotu primárního klíče. Takže vyhledávání v neshlukovaném indexu jsou ve skutečnosti dvě prohledávání B-stromu, první k nalezení listu neshlukovaného indexu a pak druhé hledání v seskupeném indexu.
To je dvojnásobek nákladů na vyhledávání v jediném B-stromu (víceméně), takže InnoDB má další funkci nazvanou Adaptivní index hash . Často hledané hodnoty se uloží do mezipaměti v AHI a až bude dotaz příště hledat hodnotu uloženou v mezipaměti, může provést vyhledávání O(1). V mezipaměti AHI najde ukazatel přímo na list seskupeného indexu, takže eliminuje obojí Část času prohledává B-strom.
Jak moc to zlepší celkový výkon, závisí na tom, jak často hledáte stejné hodnoty, které byly hledány dříve. Podle mých zkušeností je typický poměr mezi vyhledáváním typu hash a vyhledáváním bez hashování přibližně 1:2.
Q4. Sestavte indexy tak, aby obsluhovaly dotazy, které potřebujete optimalizovat. Klastrovaný index je obvykle primární nebo jedinečný klíč a alespoň v případě InnoDB je to vyžadováno. Ani age ani salary bude pravděpodobně unikátní.
Možná se vám bude líbit moje prezentace Jak navrhovat indexy, opravdu .
O5. InnoDB automaticky vytvoří index, když deklarujete jedinečné omezení. Nemůžete mít omezení, aniž by pro něj existoval index. Pokud byste neměli index, jak by engine zajistil jedinečnost, když vložíte hodnotu? Muselo by to prohledat celou tabulku a najít v tomto sloupci duplicitní hodnotu. Index pomáhá učinit jedinečné kontroly mnohem efektivnějšími.