Słowa są dość logiczne i dość szybko się ich nauczysz. :)
Mówiąc prościej, SEEK oznacza wyszukiwanie dokładnych lokalizacji dla rekordów, co robi SQL Server, gdy kolumna, w której przeszukujesz, jest indeksowana, a filtr (warunek WHERE) jest wystarczająco dokładny.
SKANOWANIE oznacza większy zakres wierszy, w których planista wykonywania zapytań szacuje, że szybsze jest pobranie całego zakresu, w przeciwieństwie do indywidualnego wyszukiwania każdej wartości.
I tak, możesz mieć wiele indeksów na tym samym polu, a czasami może to być bardzo dobry pomysł. Pobaw się indeksami i użyj planera wykonywania zapytań, aby określić, co się stanie (skrót w SSMS:Ctrl + M). Możesz nawet uruchomić dwie wersje tego samego zapytania, a planer wykonania z łatwością pokaże, ile zasobów i czasu zajmuje każda z nich, dzięki czemu optymalizacja jest całkiem łatwa.
Ale żeby nieco je rozwinąć, załóżmy, że masz taką tabelę adresów, która zawiera ponad miliard rekordów:
CREATE TABLE ADDRESS
(ADDRESS_ID INT -- CLUSTERED primary key ADRESS_PK_IDX
, PERSON_ID INT -- FOREIGN KEY, NONCLUSTERED INDEX ADDRESS_PERSON_IDX
, CITY VARCHAR(256)
, MARKED_FOR_CHECKUP BIT
, **+n^10 different other columns...**)
Teraz, jeśli chcesz znaleźć wszystkie informacje o adresie osoby 12345, indeks PERSON_ID jest idealny. Ponieważ tabela zawiera mnóstwo innych danych w tym samym wierszu, utworzenie indeksu nieklastrowanego obejmującego wszystkie inne kolumny oraz PERSON_ID byłoby nieefektywne i zajmujące dużo miejsca. W takim przypadku SQL Server wykona indeks SEEK w indeksie w PERSON_ID, a następnie użyje go do przeprowadzenia wyszukiwania klucza w indeksie klastrowym w ADDRESS_ID, a następnie zwróci wszystkie dane we wszystkich innych kolumnach w tym samym wierszu.
Załóżmy jednak, że chcesz wyszukać wszystkie osoby w mieście, ale nie potrzebujesz innych informacji adresowych. Tym razem najskuteczniejszym sposobem byłoby utworzenie indeksu na CITY i użycie opcji INCLUDE, aby pokryć również PERSON_ID. W ten sposób pojedyncze wyszukiwanie/skanowanie indeksu zwróciłoby wszystkie potrzebne informacje bez konieczności sprawdzania indeksu CLUSTERED pod kątem danych PERSON_ID w tym samym wierszu.
Załóżmy, że oba te zapytania są wymagane, ale nadal są dość ciężkie z powodu 1 miliarda rekordów. Ale jest jedno specjalne zapytanie, które musi być naprawdę szybkie. Zapytanie to obejmuje wszystkie osoby pod adresami, które zostały oznaczone jako MARKED_FOR_CHECKUP i które muszą mieszkać w Nowym Jorku (zignoruj cokolwiek oznacza sprawdzenie, to nie ma znaczenia). Teraz możesz chcieć utworzyć trzeci, filtrowany indeks dla MARKED_FOR_CHECKUP i CITY, z INCLUDE obejmującym PERSON_ID, z filtrem CITY ='Nowy Jork' i MARKED_FOR_CHECKUP =1. Ten indeks byłby niesamowicie szybki, ponieważ zawsze obejmuje tylko zapytania które spełniają dokładnie te warunki, a zatem mają ułamek danych do przejścia w porównaniu z innymi indeksami.
(Zastrzeżenie tutaj, pamiętaj, że planer wykonywania zapytań nie jest głupi, może używać wielu nieklastrowanych indeksów razem, aby uzyskać prawidłowe wyniki, więc powyższe przykłady mogą nie być najlepszymi dostępnymi, ponieważ bardzo trudno jest sobie wyobrazić, kiedy będziesz potrzebować 3 różne indeksy obejmujące tę samą kolumnę, ale jestem pewien, że masz pomysł.)
Rodzaje indeksów, ich kolumny, zawarte kolumny, porządki sortowania, filtry itp. zależą wyłącznie od sytuacji. Będziesz musiał stworzyć indeksy pokrywające, aby spełnić kilka różnych typów zapytań, a także dostosowane indeksy stworzone specjalnie dla pojedynczych, ważnych zapytań. Każdy indeks zajmuje miejsce na dysku twardym, więc tworzenie bezużytecznych indeksów jest marnotrawstwem i wymaga dodatkowej konserwacji za każdym razem, gdy zmienia się model danych, a także marnuje czas na operacje defragmentacji i aktualizacji statystyk… więc nie chcesz po prostu umieszczać indeksu na wszystkim albo.
Eksperymentuj, ucz się i opracuj, co najlepiej odpowiada Twoim potrzebom.
