Indeks, klastrowany lub nieklastrowany, może być używany przez optymalizator zapytań tylko wtedy, gdy filtrowany jest klucz indeksu znajdujący się najbardziej po lewej stronie. Więc jeśli zdefiniujesz indeks dla kolumn (A, B, C), warunek WHERE na [email protected] , na [email protected] lub na [email protected] AND [email protected] nie wykorzysta w pełni indeksu (patrz uwaga). Dotyczy to również warunków przyłączenia. Dowolny filtr WHERE zawierający A rozważy indeks:[email protected] lub [email protected] AND [email protected] lub [email protected] AND [email protected] lub [email protected] AND [email protected] AND [email protected] .
Więc w twoim przykładzie, jeśli utworzysz indeks klastrowy na part_no jako klawisz po lewej stronie, a następnie zapytanie szukające określonego part_id nie użyj indeksu, a oddzielny indeks nieklastrowy musi istnieć w part-id .
A teraz pytanie, który z wielu indeksów powinien być zgrupowany jeden. Jeśli masz kilka wzorców zapytań o tym samym znaczeniu i częstotliwości, które są ze sobą sprzeczne pod względem potrzebnych kluczy (np. częste zapytania przez albo part_no lub part_id ) bierzesz pod uwagę inne czynniki:
- szerokość :klucz indeksu klastrowego jest używany jako klucz wyszukiwania przez all inne indeksy nieklastrowe. Więc jeśli wybierzesz szeroki klucz (powiedzmy dwie kolumny z uniquidentifier), to sprawisz, że wszystkie inne indeksy będą szersze, tym samym zużywając więcej miejsca, generując więcej IO i spowalniając wszystko. Tak więc między równie dobrymi kluczami z punktu widzenia odczytu, wybierz najwęższy jako zgrupowany, a szersze nie zgrupuj.
- spór :jeśli masz określone wzorce wstawiania i usuwania, spróbuj rozdzielić je fizycznie, aby występowały w różnych częściach indeksu klastrowego. Np. jeśli tabela działa jak kolejka ze wszystkimi wstawkami na jednym logicznym końcu i wszystkimi usuniętymi na drugim logicznym końcu, spróbuj ustawić indeks klastrowy tak, aby kolejność fizyczna odpowiadała tej logicznej kolejności (np. kolejność kolejkowania).
- partycjonowanie :jeśli tabela jest bardzo duża i planujesz wdrożyć partycjonowanie, kluczem partycjonowania musi być indeks klastrowy. Typowym przykładem są dane historyczne, które są archiwizowane przy użyciu schematu partycjonowania z przesuwanym oknem. Nawet jeśli jednostki mają logiczny klucz podstawowy, taki jak „entity_id”, indeks klastrowy jest wykonywany przez kolumnę daty i godziny, która jest również używana do funkcji partycjonowania.
- stabilność :klucz, który często się zmienia, jest słabym kandydatem na klucz klastrowy, ponieważ każdy aktualizuje wartość klucza klastrowego i wymusza wszystkie indeksy nieklastrowe, aby zaktualizować przechowywany klucz wyszukiwania. Ponieważ aktualizacja klucza klastrowego prawdopodobnie przeniesie rekord na inną stronę, może to spowodować fragmentację indeksu klastrowego.
Uwaga:nie w pełni wykorzystać, ponieważ czasami wyszukiwarka wybiera indeks nieklastrowany do skanowania zamiast indeksu klastrowego po prostu dlatego, że jest węższy, a zatem ma mniej stron do przeskanowania. W moim przykładzie, jeśli masz indeks na (A, B, C) i filtr WHERE na [email protected] i projekty zapytań C , indeks prawdopodobnie będzie używany, ale nie jako wyszukiwanie, jako skanowanie, ponieważ nadal jest szybsze niż pełne skanowanie klastrowe (mniej stron).
