MSSQL - kiedy używać indeksów

Hej wszystkim,

Wydaje mi się że mam popularny przypadek, ale niestety nie mogę znaleźć jasnej odpowiedzi. Przyjmijmy że mamy tabelę Comment, która ma kolumny:

COMMENT

• ID (PK)
• Subject (Varchar)
• Content (Varchar)
• Author (Varchar)
• DocumentID (Varchar)

no i zamierzamy często wyciągać dane dla danego DocumentId, coś w stylu SELECT * FROM COMMENT WHERE DocumentID = ...
DocumentId to 10-cyfrowy string. Chcę żeby query zwracało szybko wyniki, bez względu na to ile jest danych w tabeli. Czy widzicie tu jakieś zastosowanie indeksów? Z tego co widzę to indeks klastrowany dla DocumentId posortuje mi dane po DocumentID czego za bardzo nie chcę (chcę mieć dane posortowane po kluczu głównym, ID), a indeks nieklastrowany w cale nie poprawi wyszukiwania - byłby przydatny jakbym chciał pobrać tylko i wyłącznie DocumentID,

Jako laik bazodanowy proszę Was o radę czy pozostawienie zwykłej varcharowej kolumny będzie OK.

platinium napisał(a):

a indeks nieklastrowany w cale nie poprawi wyszukiwania - byłby przydatny jakbym chciał pobrać tylko i wyłącznie DocumentID,

skąd taki pomysł? "10-cyfrowy string"? Jeśli zawiera tylko cyfry to czemu nie jest liczbą? Wyszukiwanie po stringach jest wolne. Czemu DocumentID nie jest kluczem głównym skoro po nim chcesz głównie identyfikować rekordy? Jaką różnicę robi ci w jaki sposób są posortowane dane w bazie?

Na 99,9% pk jest clustered index, w tabeli może być tylko jeden więc nowy będzie nonclustered.

Z tego co piszesz index na documentid wydaje się rozsądnym pomysłem, pytanie tylko czy masz faktycznie problem z czasem zapytań.

indeks nieklastrowany w cale nie poprawi wyszukiwania - byłby przydatny jakbym chciał pobrać tylko i wyłącznie DocumentID,

A czytałeś w ogóle o tym jak działają indeksy? Jak dodasz indeks na kolumnę DocumentID to w czasie wyszukiwania po DocumentId silnik bazy wyszuka sobie odpowiedni wpis w strukturze indeksu a następnie mając informacje które rekordy mają zostać zwrócone to pobierze je sobie z tabeli. Jeśli nie będziesz miał indeksu na tej kolumnie to za każdym razem silnik będzie wykonywał pełen skan tabeli co może być dużo mniej wydajne. Może nie za każdym, nie jestem teraz pewny czy sql server ma jakiś cache.
To czy indeks zostanie użyty czy nie to też nie zawsze jest oczywiste, może się okazać że mechanizmy optymalizacyjne bazy uznają że wykonanie pełnego skanu tabeli będzie lepsze.

var napisał(a):

indeks nieklastrowany w cale nie poprawi wyszukiwania - byłby przydatny jakbym chciał pobrać tylko i wyłącznie DocumentID,

A czytałeś w ogóle o tym jak działają indeksy? Jak dodasz indeks na kolumnę DocumentID to w czasie wyszukiwania po DocumentId silnik bazy wyszuka sobie odpowiedni wpis w strukturze indeksu a następnie mając informacje które rekordy mają zostać zwrócone to pobierze je sobie z tabeli.

Lub bezpośrednio z indeksu, jeśli te kolumny będą dołączone do tego indeksu.
W MSSQL istnieje coś takiego jak included columns dla indeksu.

Jeśli nie będziesz miał indeksu na tej kolumnie to za każdym razem silnik będzie wykonywał pełen skan tabeli co może być dużo mniej wydajne. Może nie za każdym, nie jestem teraz pewny czy sql server ma jakiś cache.

Nie tylko ma cache, ale silnik sam sobie może tu odpowiednie statystyki utworzyć.

To czy indeks zostanie użyty czy nie to też nie zawsze jest oczywiste, może się okazać że mechanizmy optymalizacyjne bazy uznają że wykonanie pełnego skanu tabeli będzie lepsze.

Tak, ale to już naprawdę mocno zależy.