Jeśli tabela zawiera indeks klastrowany w kluczu podstawowym (int), jest zbędna i zła, aby mieć jeden (lub więcej) indeksy nieklastrowe, które zawierają kolumnę klucza głównego jako jedną z kolumn w kluczu indeks klastrowany?Czy jest źle mieć indeks klastrowany, który zawiera klucz podstawowy z indeksu klastrowanego?
Właściwie mogą istnieć uzasadnione powody, aby utworzyć nieklastrowany indeks identyczny z klastrem. Powodem jest to, że indeksy klastrowe niosą bagaż danych rzędu, co może powodować bardzo słabą gęstość rzędów. To znaczy. możesz mieć 2-3 wiersze na stronę ze względu na szerokie pola, które nie znajdują się w kluczu klastrowym, ale klastrowany klucz indeksu ma tylko 20 bajtów. Posiadanie niesklasyfikowanego indeksu na dokładnie tego samego klucza (ów) i porządku, jak indeks klastrowy dałby gęstość 2-3 setek kluczy na stronie. Wiele agregatów kwerend typowych dla obciążenia OLAP/BI może być bardziej efektywnie odpowiedzianych przez indeks nieklastrowy, po prostu dlatego, że zmniejsza on I/O setki razy.
Co do indeksów nieklastrowych, które zawierają części klucza klastrowanego, lub nawet te same klucze, ale w innej kolejności, wszystkie zakłady są wyłączone, ponieważ można je oczywiście wykorzystać do wielu zapytań.
Więc odpowiedź na twoje pytanie jest: To zależy od.
Aby uzyskać bardziej precyzyjną odpowiedź, musisz podać dokładny schemat swoich tabel i dokładnych zapytań.
Nie ma 100% odpowiedzi, ale odpowiedź jest prawie na pewno.
Pozostałe indeksy pomagają w łączeniach i sortowaniu (ogólnie). Biorąc pod uwagę, że klucz podstawowy jest już zaindeksowany, jeśli optymalizator może się przyłączyć, na podstawie tego, że będzie go używać.
Jeśli potrzebny jest inny indeks z perspektywy łączenia/sortowania, to jaka dodatkowa pomoc ma zastosowanie PK w zestawie indeksów? Jeśli nie może się on połączyć w oparciu o PK, nie będzie to teraz. I tak naprawdę nie pomoże też przy sortowaniu.
Tak, zazwyczaj nie jest to konieczne, ponieważ kolumny indeksu klastrowego są już dodane do każdej pozycji indeksu w indeksie nieklastrowym.
Dlaczego? Wartość klucza klastrowanego jest tym, co naprawdę pozwala programowi SQL Server "znaleźć" wiersz danych - jest to "wskaźnik" do rzeczywistych danych - tak więc musi być zapisany w indeksie nieklastrowanym. Jeśli spojrzałeś na "Smith, John" i musisz dowiedzieć się więcej o tej osobie, musisz przejść do rzeczywistych danych -> i odbywa się to poprzez uwzględnienie wartości klucza klastrowania w węźle indeksu indeks klastrowany.
Ta wartość klucza klastrowanego już istnieje i dlatego zwykle jest zbędne i niepotrzebne, aby ponownie dodać tę wartość, jawnie, do indeksu nieklastrowego. Jest to złe, ponieważ po prostu marnuje przestrzeń, nie dając żadnych korzyści.
Jestem z Remusem na tym - indeks klastrowany nie jest tak naprawdę indeksem - informuje, w jaki sposób dane są uporządkowane na stronach. (W twoim przypadku jest to również klucz podstawowy, ale nie musi to być ta sama rzecz). Indeksy nieklastrowe zawierają informacje o lokalizacji wiersza, więc tak, jest to zbędne.
Ale jeśli nieklastrowanych indeksu obejmującegoi wierszu danych zakładka nie muszą być stosowane, może być używany dużo skuteczniej niż indeks klastrowany i efektywności wzrasta wraz ze wzrostem stosunku rozmiaru wiersza danych do rozmiaru wskaźnika nieklastrowego.
Znalazłem, że jeśli masz dobrą obsługę ścieżek dostępu w obciążeniu zapytaniami, to czasami kilka selektywnych obejmujących nieklastrowych indeksów często może być używanych do całkowitego wyeliminowania wyboru klastrów - sterty sterty, PK, i kilka dobrych indeksów nieklastrowych, i gotowe.