Indeksy wielokrotne a indeksy wielokolumnowe

645

Właśnie dodałem Indeks do tabeli w SQL Server 2005 i to sprawiło, że pomyślałem. Jaka jest różnica między utworzeniem 1 indeksu a zdefiniowaniem wielu kolumn w porównaniu z posiadaniem 1 indeksu na kolumnę, którą chcesz indeksować.

Czy istnieją pewne powody, dla których jedno powinno być używane w stosunku do drugiego?

Na przykład

Create NonClustered Index IX_IndexName On TableName
(Column1 Asc, Column2 Asc, Column3 Asc)

Przeciw

Create NonClustered Index IX_IndexName1 On TableName
(Column1 Asc)

Create NonClustered Index IX_IndexName2 On TableName
(Column2 Asc)

Create NonClustered Index IX_IndexName3 On TableName
(Column3 Asc)
sql-server database indexing GateKiller
źródło

Odpowiedzi:

319

Zgadzam się z Cade Roux .

Ten artykuł powinien doprowadzić Cię na właściwą drogę:

Należy zauważyć, że indeksy klastrowe powinny mieć unikalny klucz (kolumnę tożsamości polecam) jako pierwszą kolumnę. Zasadniczo pomaga wstawiać dane na końcu indeksu i nie powoduje wielu dyskowych operacji we / wy i podziału strony.

Po drugie, jeśli tworzysz inne indeksy na swoich danych, które są sprytnie skonstruowane, zostaną ponownie wykorzystane.

np. wyobraź sobie, że przeszukujesz tabelę w trzech kolumnach

stan, hrabstwo, zip.

  • czasami wyszukujesz tylko według stanu.
  • czasami wyszukujesz według stanu i hrabstwa.
  • często wyszukujesz według stanu, hrabstwa, zip.

Następnie indeks ze stanem, hrabstwem, zip. będą używane we wszystkich tych trzech wyszukiwaniach.

Jeśli dość często przeszukujesz sam zip, powyższy indeks nie zostanie użyty (w każdym razie SQL Server), ponieważ zip jest trzecią częścią tego indeksu, a optymalizator zapytań nie uzna tego indeksu za pomocny.

Następnie możesz utworzyć indeks samego Zip, który byłby używany w tym przypadku.

Nawiasem mówiąc, możemy skorzystać z faktu, że przy indeksowaniu wielokolumnowym pierwsza kolumna indeksu jest zawsze przydatna do wyszukiwania, a gdy wyszukujesz tylko według „stanu”, jest to wydajne, ale nie tak skuteczne jak indeks jednokolumnowy dla „stanu” „

Wydaje mi się, że odpowiedź, której szukasz, polega na tym, że zależy to od tego, gdzie znajdują się klauzule często używanych zapytań, a także od twojej grupy.

Artykuł bardzo pomoże. :-)

evilhomer
źródło
2
Czy więc najlepszym rozwiązaniem byłoby zdefiniowanie indeksu stanu, hrabstwa i zipu oprócz indywidualnego indeksu dla każdej kolumny?
Maxim Zaslavsky
12
@jball Czy coś mi brakuje? Wygląda na to, że artykuł dotyczy głównie różnic między ograniczeniami wersji programu SQL Server. Czy artykuł mógł zostać przeniesiony?
Ian R. O'Brien
@ Ian wygląda na to, że coś zaginęło w ciągu 3 lat, odkąd uporządkowałem oryginalny link z 4 lat temu. Mogę powiedzieć, że post na blogu ma prawidłowy tytuł, do którego prowadzi link evilhomer, ale wygląda na to, że kolejne blogi z tej serii nie są już łatwo dostępne z tego pierwszego postu. Będziesz musiał przejrzeć archiwum blogów Kimberly, aby zobaczyć, czy możesz podkręcić inne w serii.
jball
1
1) „Zasadniczo [Indeks klastrowany z kolumną TOŻSAMOŚĆ jako pierwsza] pomaga wstawiać dane na końcu indeksu” jest poprawny. „i nie powoduje wielu dyskowych operacji we / wy i podziału strony” jest całkowicie fałszywe w systemie z wieloma użytkownikami. Prawda jest taka, że gwarantuje wysoką rywalizację (niską współbieżność) w systemie dla wielu użytkowników. 2) Indeks klastrowy powinien być kluczem relacyjnym, tj. nie an IDENTITY, GUID, etc. 3) „Następnie we wszystkich trzech wyszukiwaniach zostanie użyty indeks ze stanem, hrabstwem i zip.” jest fałszywe i jest sprzeczne z „pierwszą kolumną nadającą się do użytku”. Kolumny 2nd i sub w indeksie nie nadają się do wyszukiwania.
PerformanceDBA
82

Tak. Polecam przejrzenie artykułów Kimberly Tripp na temat indeksowania .

Jeśli indeks „obejmuje”, nie ma potrzeby używania niczego poza indeksem. W SQL Server 2005 można również dodawać do indeksu dodatkowe kolumny, które nie są częścią klucza, co może wyeliminować przejazdy do pozostałej części wiersza.

Mając wiele indeksów, każdy w jednej kolumnie może oznaczać, że w ogóle używany jest tylko jeden indeks - będziesz musiał zapoznać się z planem wykonania, aby zobaczyć, jakie efekty oferują różne schematy indeksowania.

Możesz także użyć kreatora strojenia, aby ustalić, które indeksy spowodowałyby, że dane zapytanie lub obciążenie działałoby najlepiej.

Cade Roux
źródło
7
Kimberly Tripp wie o czym mówi. Rozmawiałem z nią, a ona zna te rzeczy na wylot. Dobra rada.
evilhomer
@CadeRoux Jeśli większość razy moja klauzula where ma 2 kolumny w relacji „&”, czy lepiej będzie mieć indeks wielokolumnowy lub indeks jednokolumnowy na obu z nich
To pułapka
2
@RachitGupta Jeden indeks z obiema kolumnami
Cade Roux
41

Indeks wielokolumnowy może być używany do zapytań odnoszących się do wszystkich kolumn:

SELECT *
FROM TableName
WHERE Column1=1 AND Column2=2 AND Column3=3

Można to sprawdzić bezpośrednio za pomocą indeksu wielokolumnowego. Z drugiej strony można użyć maksymalnie jednego indeksu jednokolumnowego (musiałby wyszukać wszystkie rekordy mające Kolumnę1 = 1, a następnie zaznaczyć Kolumnę2 i Kolumnę3 w każdym z nich).

MobyDX
źródło
24
To jest poprawne. Jednak posiadanie tych kolumn jako jednego indeksu nadal znacznie przyspieszyłoby sprawę. Zwykle jedna z wartości w kolumnach zmniejsza wynikowy zestaw tak bardzo, że nie ma znaczenia wyszukiwanie pozostałych bez indeksu, a optymalizator dobrze wybiera tę wartość.
TToni
17

Jednym z elementów, który wydaje się być pominięty, są transformacje gwiazd. Operatory przecięcia indeksu rozwiązują predykat, obliczając zbiór wierszy trafionych przez każdy z predykatów, zanim jakiekolwiek operacje we / wy zostaną wykonane w tabeli faktów. W schemacie gwiaździstym indeksowałbyś każdy klucz wymiaru, a optymalizator zapytań może rozstrzygnąć, które wiersze wybrać na podstawie obliczeń przecięcia indeksu. Indeksy w poszczególnych kolumnach zapewniają najlepszą elastyczność.

ConcernedOfTunbridgeWells
źródło
+1 za połączone dobre wyjaśnienie, w jaki sposób stosowane są (zwykłe) indeksy, odpowiednie do pytania.
RobM,
8

Jeśli masz zapytania, które często będą używać względnie statycznego zestawu kolumn, utworzenie jednego indeksu obejmującego je wszystkie znacznie poprawi wydajność.

Po umieszczeniu wielu kolumn w indeksie optymalizator będzie musiał uzyskać bezpośredni dostęp do tabeli tylko wtedy, gdy kolumny nie ma w indeksie. Dużo ich używam w hurtowni danych. Minusem jest to, że robienie tego może kosztować dużo narzutu, szczególnie jeśli dane są bardzo niestabilne.

Tworzenie indeksów w pojedynczych kolumnach jest przydatne do operacji wyszukiwania często spotykanych w systemach OLTP.

Powinieneś zadać sobie pytanie, dlaczego indeksujesz kolumny i jak będą one używane. Uruchom niektóre plany zapytań i sprawdź, kiedy są dostępne. Strojenie indeksów jest tak samo instynktowne jak nauka.

Bob Probst
źródło