Trudno to określić bardziej zwięźle niż MVP SQL Server Brad McGehee:
Zasadniczo każda tabela powinna mieć indeks klastrowy. Ogólnie, ale nie zawsze, indeks klastrowy powinien znajdować się w kolumnie, która stale rośnie — na przykład w kolumnie tożsamości lub w innej kolumnie, w której wartość rośnie — i jest unikatowa. W wielu przypadkach klucz podstawowy jest idealną kolumną dla indeksu klastrowego.
BOL powtarza ten sentyment:
Z kilkoma wyjątkami, każda tabela powinna mieć indeks klastrowy.
Powodów takiego postępowania jest wiele i opierają się one głównie na fakcie, że indeks klastrowy fizycznie porządkuje dane w pamięci .
-
Jeśli indeks klastrowy znajduje się w jednej kolumnie, monotonicznie wzrasta, wstawianie następuje w kolejności na urządzeniu pamięci masowej, a podziały stron nie będą miały miejsca.
-
Indeksy klastrowe są wydajne w znajdowaniu określonego wiersza, gdy zindeksowana wartość jest unikatowa, na przykład typowy wzorzec wybierania wiersza na podstawie klucza podstawowego.
-
Indeks klastrowy często pozwala na wydajne zapytania dotyczące kolumn, które są często przeszukiwane pod kątem zakresów wartości (
pomiędzy,> itp.). -
Grupowanie może przyspieszyć zapytania, w których dane są często sortowane według określonej kolumny lub kolumn.
-
Indeks klastrowy można odbudować lub zreorganizować na żądanie, aby kontrolować fragmentację tabeli.
-
Korzyści te można zastosować nawet do widoków.
Możesz nie chcieć mieć indeksu klastrowego na:
-
Kolumny, w których dane często się zmieniają, ponieważ SQL Server musi wtedy fizycznie zmienić kolejność danych w pamięci.
-
Kolumny, które są już objęte innymi indeksami.
-
Klucze szerokie, ponieważ indeks klastrowy jest również używany w wyszukiwaniu indeksów nieklastrowych.
-
Kolumny GUID, które są większe niż tożsamości, a także skutecznie losowe wartości (prawdopodobnie nie będą sortowane), chociaż
newsectionid()może być użyty do złagodzenia fizycznej zmiany kolejności podczas wstawiania. -
Rzadkim powodem używania sterty (tabeli bez indeksu klastrowego) jest to, że dostęp do danych jest zawsze możliwy za pośrednictwem indeksów nieklastrowych, a RID (wewnętrzny identyfikator wiersza programu SQL Server) jest mniejszy niż klucz indeksu klastrowego.
Ze względu na te i inne względy, takie jak określone obciążenia aplikacji, należy ostrożnie wybierać indeksy klastrowane, aby uzyskać maksymalne korzyści z zapytań.
Pamiętaj też, że kiedy tworzysz klucz podstawowy w tabeli w SQL Server, domyślnie tworzy on unikalny indeks klastrowy (jeśli jeszcze go nie ma). Oznacza to, że jeśli znajdziesz tabelę, która nie ma indeksu klastrowego, ale ma klucz podstawowy (tak jak wszystkie tabele), deweloper podjął wcześniej decyzję o utworzeniu jej w ten sposób. Możesz chcieć mieć przekonujący powód, aby to zmienić (których jest wiele, jak widzieliśmy). Dodanie, zmiana lub usunięcie indeksu klastrowego wymaga przepisania całej tabeli i wszelkie indeksy nieklastrowane, więc może to zająć trochę czasu w przypadku dużej tabeli.
