W przypadku zapytań obejmujących małe fragmenty wierszy tabeli, indeksy są zawsze korzystne, bądź tam 100 wierszy lub .
Zobacz ten wpis w moim blogu na przykładach z planów i szczegółów Osiągi:
zapytań tak:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
najprawdopodobniej korzystania HASH JOIN. Zostanie zbudowana tablica mieszająca dla mniejszej tabeli, a wiersze z większej tabeli będą używane do sprawdzania tabeli mieszania.
Aby to zrobić, indeks nie jest potrzebny.
jednak to zapytanie:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
WHERE t1.othercol = @value
użyje NESTED LOOPS: wiersze z tabeli zewnętrznej (table1) będą wyszukiwane za pomocą indeksu table1.othercol i wiersze z tabeli wewnętrznej (table2) będzie wyszukiwane przy użyciu indeksu na table2.col.
Jeśli nie masz indeksu na col1, A HASH JOIN zostaną wykorzystane który wymaga skanując wszystkie wiersze z obu tabel, a niektóre więcej środków na wbudowanym tabeli mieszania.
Indeksy są również użyteczne dla zapytań takich jak ten:
SELECT t2.col
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
, w takim przypadku silnik nie trzeba czytać table2 sama w ogóle: eveything trzeba dla tego zapytania można znaleźć w indeksie , która może być znacznie mniejsza niż sama tabela i bardziej wydajna do czytania.
I, oczywiście, jeśli potrzebujesz dane sortowane i mają indeksy zarówno table1.col i table2.col, to następujące zapytanie:
SELECT *
FROM table1 t1
JOIN table2 t2
ON t2.col = t1.col
ORDER BY
t2.col
będzie prawdopodobnie używać MERGE JOIN metodę, która jest super szybki, gdy oba zestaw wierszy wejściowych są sortowane, a ich dane wyjściowe są również sortowane, co oznacza, że ORDER BY jest bezpłatne.
Należy pamiętać, że nawet jeśli nie masz indeksu, optymalizator może wybrać dla swojej małej tabeli wartość Eager Spool, co oznacza utworzenie indeksu tymczasowego na czas trwania zapytania i usunięcie indeksu po zakończeniu zapytania.
Jeśli zapytanie jest małe, będzie bardzo szybkie, ale ponownie indeks nie zaszkodzi (mam na myśli zapytania o numerach SELECT). Jeśli optymalizator nie będzie tego potrzebować, po prostu nie będzie używany.
Należy jednak pamiętać, że tworzenie indeksu może mieć wpływ na wydajność DML, ale jest to inna historia.
W rzeczywistości baza danych nie sortuje kluczy w obrębie jednej strony. Więc dopóki nie przekroczy tego punktu, nie ma żadnej korzyści. I prawdopodobnie na kilka stron dalej. – dkretz
@Robert: przynoszą również korzyści, gdy używasz tylko indeksowanych kolumn w zapytaniu lub gdy potrzebujesz posortować dane. I nie, nie zawsze są one korzystne dla klauzuli WHERE, tylko w przypadku bardzo selektywnych. – Quassnoi
Quassnoi, widziałem twój blog. Tak, więc wiesz, ostateczna decyzja o indeksowaniu naszej bazy danych (na podstawie dodatkowych informacji pod tym postem: stackoverflow.com/questions/1033796/...) polegała na indeksowaniu wszystkich kluczy obcych, Z WYJĄTKIEM tych, którzy uczestniczą w połączeniach z tabelami wyszukiwania zawierającymi MNIEJ NIŻ 10 DOKUMENTACJA. –