Indeksy klastrowe SQL Server

Question

Posiadam tło Oracle, a używanie "indeksowanych uporządkowanych tabel" (IOT) dla każdej tabeli wydaje się nierozsądne w Oracle i tak naprawdę nigdy tego nie widziałem. W SQL Server każda baza danych, na której pracowałem, ma indeks klastrowany na każdej tabeli, która jest taka sama jak IOT (koncepcyjnie).

Dlaczego tak jest? Czy jest jakikolwiek powód, aby wszędzie korzystać z indeksu klastrowego? Wydaje mi się, że będą dobre tylko dla garstki przypadków.

Dzięki

Answer 1

Bez indeksu klastrowanego tabela jest zorganizowana jako sterty. Oznacza to, że każdy wiersz będący insertem jest dodawany na stronie danych na końcu tabeli. Również, gdy wiersze są aktualizowane, zostają przeniesione na stronę danych na końcu tabeli, jeśli zaktualizowane dane są większe niż poprzednio.

Kiedy dobrze jest nie mieć indeks klastrowany

Jeśli masz tabelę, która musi najszybsze wkładki, ale można poświęcić aktualizacji i odczytu prędkości, wtedy nie ma wskaźnik klastra mogą pracować ty. Przykładem może być tabela, która była używana jako kolejka, na przykład wiele wstawek, które później zostaną odczytane i przeniesione do innej tabeli.

Klastrowe Indeksy

indeksów klastrowanych organizować dane w tabeli na podstawie kolumn w indeksie klastrowym. Jeśli skupisz się na niewłaściwej rzeczy, na przykład unikalnego identyfikatora, może to spowolnić działanie (patrz poniżej).

Dopóki indeks klastrowy znajduje się na wartości, która jest najczęściej używana do wyszukiwania, i jest unikalna i zwiększa się, można uzyskać niesamowite korzyści wydajnościowe z indeksu klastrowego.Na przykład, jeśli masz tabelę o nazwie UŻYTKOWNICY, w której często szuka się danych użytkownika na podstawie USER_ID, wówczas grupowanie na USER_ID przyspieszyłoby wydajność wszystkich tych wyszukiwań. Zmniejsza to po prostu liczbę stron danych, które należy odczytać, aby uzyskać dostęp do danych.

Jeśli masz zbyt wiele kluczy w indeksie klastrowanym, może to również spowolnić działanie.

Ogólne zasady skupionych indeksów:

Nie klastra na jakichkolwiek kolumn varchar.

Klastrowanie na kolumnach IDENTYFIKACJI INT jest zwykle najlepsze.

Klaster dotyczący najczęściej wyszukiwanych haseł.

Klastry na UniqueIdentifiers

Z uniqueidentifiers w indeksie, są bardzo nieefektywne, ponieważ nie istnieje naturalny porządek. W oparciu o strukturę drzewa b-indeksu uzyskuje się skrajnie pofragmentowane indeksy przy użyciu uniqueidentifiers. Po przebudowie lub reorganizacji są nadal bardzo rozdrobnione. Więc kończy się wolniejszym indeksem, który w efekcie jest bardzo duży w pamięci i na dysku z powodu fragmentacji. Również w przypadku insertów identyfikatora unikatowego bardziej prawdopodobne jest, że strona zostanie podzielona na indeks, co spowalnia wstawianie. Ogólnie rzecz biorącidentyfikatory są złe dla indeksów.

Podsumowanie

Moja rada jest taka, że ​​każda tabela powinna mieć klastrowego indeks na nim, chyba że jest to naprawdę dobry powód, aby nie (czyli tabela funkcjonują jako kolejka).

Answer 2

Używamy klucz podstawowy w relacyjnych bazach danych iw ogólnym zakresie ustalono za pomocą tych kluczy podstawowych. Większość ludzi używała nazwy pierwszego pola jako TableID i uczyniła go kluczem podstawowym. Po połączeniu dwóch lub więcej tabel w zapytaniu uzyskasz najszybszy wynik, jeśli użyjesz indeksów klastrowych.

Answer 3

Nie wiedziałbym, dlaczego wolisz kupkę ponad indeks klastrowany przez większość czasu. Korzystając z klastrowania, otrzymujesz za darmo jeden wybrany przez siebie indeks. W większości przypadków jest to klucz podstawowy (który prawdopodobnie i tak chcesz wymusić!).

Sterty są głównie do zastosowań specjalnych.

Answer 4

Indeks klastrowany to nie to samo, co tabela zorganizowana według indeksu. W IOT każde pole musi uczestniczyć w kluczu IOT. Indeks klastrowany na serwerze SQL Server nie musi być unikalny i nie musi być kluczem podstawowym.

Indeksy klastrowe są szeroko stosowane na serwerze SQL Server, ponieważ prawie zawsze występuje pewne uporządkowanie naturalne, które sprawia, że ​​często używane zapytanie jest bardziej wydajne. IOTy w Oracle mają więcej bagażu, więc nie są tak przydatne, chociaż mogą okazać się bardziej przydatne, niż są powszechnie uznawane za zasługi.

Historycznie, naprawdę stare wersje programu SQL Server wcześniejszych wersji 6.5 lub 7.0 IIRC nie obsługiwały blokowania na poziomie wiersza i mogły blokować tylko na poziomie tabeli lub strony. Często stosowano indeks klastrowy w celu zapewnienia, że ​​zapisy były rozproszone wokół fizycznej pamięci tabeli, aby zminimalizować rywalizację o blokady strony. Jednak kilka lat temu SQL Server 6 przeszedł wsparcie, więc aplikacje z tym problemem będą ograniczone do rzadko spotykanych systemów.