Nie znam się na wewnętrznej stronie Microsoft SQL Server, ale mogę odpowiedzieć na MySQL, który oznaczyłeś jako swoje pytanie. Szczegóły mogą się różnić w przypadku innych implementacji.
P1. Zgadza się, nie jest potrzebne dodatkowe miejsce na indeks klastrowy.
Co się stanie, jeśli usuniesz indeks klastrowy? Silnik MySQL InnoDB zawsze używa klucza podstawowego (lub pierwszego unikalnego klucza innego niż null) jako indeksu klastrowego. Jeśli zdefiniujesz tabelę bez klucza podstawowego lub usuniesz klucz podstawowy istniejącej tabeli, InnoDB generuje wewnętrzny sztuczny klucz dla indeksu klastrowego . Ten klucz wewnętrzny nie ma logicznej kolumny, która mogłaby się do niego odwoływać.
Q2. Nie jest gwarantowana kolejność wierszy zwracanych przez zapytanie korzystające z indeksu nieklastrowanego. W praktyce jest to kolejność dostępu do wierszy. Jeśli potrzebujesz zwracanych wierszy w określonej kolejności, użyj ORDER BY w zapytaniu. Jeśli optymalizator może wywnioskować, że żądana kolejność jest taka sama, jak kolejność, w której będzie uzyskiwać dostęp do wierszy (kolejność indeksowania, czy to według indeksu klastrowego, czy nieklastrowego), może pominąć krok sortowania.
Q3. Indeks nieklastrowy InnoDB nie ma wskaźnika do odpowiedniego wiersza na liściu indeksu, ma wartość klucza podstawowego. Tak więc wyszukiwanie w indeksie nieklastrowym to tak naprawdę dwa wyszukiwania B-drzewa, pierwsze, które znajduje liść indeksu nieklastrowego, a następnie drugie wyszukiwanie w indeksie klastrowym.
To dwa razy więcej niż koszt pojedynczego wyszukiwania B-drzewa (mniej więcej), więc InnoDB ma dodatkową funkcję o nazwie Adaptacyjny indeks skrótu . Często wyszukiwane wartości są buforowane w AHI, a następnym razem, gdy zapytanie wyszukuje buforowaną wartość, może wykonać wyszukiwanie O(1). W pamięci podręcznej AHI znajduje wskaźnik bezpośrednio do liścia indeksu klastrowego, więc eliminuje oba Poszukiwania B-drzewa, przez część czasu.
To, jak bardzo poprawia to całkowitą wydajność, zależy od tego, jak często wyszukujesz te same wartości, które były wcześniej wyszukiwane. Z mojego doświadczenia wynika, że stosunek wyszukiwań z haszowaniem do wyszukiwań bez hash wynosi około 1:2.
Q4. Skonstruuj indeksy do obsługi zapytań, które chcesz zoptymalizować. Zazwyczaj indeks klastrowy jest kluczem podstawowym lub unikalnym, a przynajmniej w przypadku InnoDB jest to wymagane. Ani age ani salary prawdopodobnie będzie wyjątkowy.
Może Ci się spodobać moja prezentacja Jak naprawdę projektować indeksy .
P5. InnoDB automatycznie tworzy indeks, gdy deklarujesz unikatowe ograniczenie. Nie możesz mieć ograniczenia bez istniejącego dla niego indeksu. Gdybyś nie miał indeksu, w jaki sposób silnik zapewniłby unikalność podczas wstawiania wartości? Musiałoby to przeszukać całą tabelę w poszukiwaniu zduplikowanej wartości w tej kolumnie. Indeks pomaga uczynić unikalne kontrole znacznie bardziej wydajnymi.
