Musisz sprawdzić dla każdego warunku gdzie i dla każdego przyłączenia... pod warunkiem. Obie działają tak samo.
Załóżmy, że piszemy
select name
from customer
where customerid=37;
Jakoś DBMS musi znaleźć rekord lub rekordy z identyfikatorem klienta=37. Jeśli nie ma indeksu, jedynym sposobem, aby to zrobić, jest odczytanie każdego rekordu w tabeli, porównując identyfikator klienta do 37. Nawet jeśli go znajdzie, nie ma możliwości sprawdzenia, że jest tylko jeden, więc musi dalej szukać inne.
Jeśli utworzysz indeks na identyfikator klienta, DBMS ma sposoby na bardzo szybkie przeszukanie indeksu. Nie jest to wyszukiwanie sekwencyjne, ale, w zależności od bazy danych, wyszukiwanie binarne lub inna wydajna metoda. Dokładnie jak nie ma znaczenia, zaakceptuj, że jest to znacznie szybsze niż sekwencyjne. Indeks następnie przenosi go bezpośrednio do odpowiedniego rekordu lub rekordów. Co więcej, jeśli określisz, że indeks jest „unikalny”, baza danych wie, że może istnieć tylko jeden, więc nie traci czasu na szukanie sekundy. (A DBMS uniemożliwi dodanie drugiego.)
Rozważmy teraz to zapytanie:
select name
from customer
where city='Albany' and state='NY';
Teraz mamy dwa warunki. Jeśli masz indeks tylko w jednym z tych pól, DBMS użyje tego indeksu, aby znaleźć podzbiór rekordów, a następnie przeszuka je sekwencyjnie. Na przykład, jeśli masz indeks dotyczący stanu, DBMS szybko znajdzie pierwszy rekord dla NY, a następnie po kolei wyszuka city='Albany' i przestanie szukać, gdy osiągnie ostatni rekord dla NY.
Jeśli masz indeks, który zawiera oba pola, tj. „Utwórz indeks dla klienta (stan, miasto)”, DBMS może natychmiast powiększyć do właściwych rekordów.
Jeśli masz dwa oddzielne indeksy, po jednym w każdym polu, DBMS będzie miał różne zasady, które stosuje, aby zdecydować, którego indeksu użyć. Ponownie, dokładnie, jak to się robi, zależy od konkretnego systemu DBMS, którego używasz, ale zasadniczo stara się prowadzić statystyki dotyczące całkowitej liczby rekordów, liczby różnych wartości i rozkładu wartości. Następnie przeszuka te rekordy sekwencyjnie pod kątem tych, które spełniają drugi warunek. W tym przypadku DBMS prawdopodobnie zaobserwowałby, że jest o wiele więcej miast niż stanów, więc korzystając z indeksu miast, może szybko powiększyć rekordy „Albany”. Następnie przeszuka je sekwencyjnie, porównując stan każdego z „NY”. Jeśli masz dane dotyczące Albany w Kalifornii, zostaną one pominięte.
Każde dołączenie wymaga pewnego rodzaju sprawdzenia.
Powiedzmy, że piszemy
select customer.name
from transaction
join customer on transaction.customerid=customer.customerid
where transaction.transactiondate='2010-07-04' and customer.type='Q';
Teraz DBMS musi zdecydować, którą tabelę odczytać jako pierwszą, wybrać z niej odpowiednie rekordy, a następnie znaleźć pasujące rekordy w drugiej tabeli.
Gdybyś miał indeks dla transaction.transactiondate i customer.customerid, najlepszym planem byłoby prawdopodobnie znalezienie wszystkich transakcji z tą datą, a następnie dla każdej z nich znalezienie klienta o pasującym identyfikatorze klienta, a następnie sprawdzenie, czy klient ma właściwy typ.
Jeśli nie masz indeksu na customer.customerid, DBMS może szybko znaleźć transakcję, ale dla każdej transakcji musiałby sekwencyjnie przeszukiwać tabelę klientów w poszukiwaniu pasującego identyfikatora klienta. (Prawdopodobnie byłoby to bardzo powolne).
Załóżmy zamiast tego, że jedyne indeksy, które masz, znajdują się na transaction.customerid i customer.type. Wtedy DBMS prawdopodobnie skorzystałby z zupełnie innego planu. Prawdopodobnie przeskanuje tabelę klientów pod kątem wszystkich klientów z prawidłowym typem, a następnie dla każdego z nich znajdzie wszystkie transakcje dla tego klienta i sekwencyjnie przeszuka je pod kątem właściwej daty.
Najważniejszym kluczem do optymalizacji jest ustalenie, jakie indeksy naprawdę pomogą i utworzenie tych indeksów. Dodatkowe, nieużywane indeksy obciążają bazę danych, ponieważ ich utrzymanie wymaga pracy, a jeśli nigdy nie są używane, jest to zmarnowany wysiłek.
Możesz określić, jakich indeksów DBMS użyje dla danego zapytania za pomocą polecenia EXPLAIN. Używam tego cały czas, aby określić, czy moje zapytania są dobrze zoptymalizowane, czy też powinienem tworzyć dodatkowe indeksy. (Przeczytaj dokumentację tego polecenia, aby uzyskać wyjaśnienie jego wyników.)
Zastrzeżenie:Pamiętaj, że powiedziałem, że DBMS prowadzi statystyki dotyczące liczby rekordów i liczby różnych wartości i tak dalej w każdej tabeli. EXPLAIN może dać ci dzisiaj zupełnie inny plan niż wczoraj, jeśli dane się zmieniły. Na przykład, jeśli masz zapytanie, które łączy dwie tabele, a jedna z tych tabel jest bardzo mała, a druga jest duża, będzie ono skłaniać się ku najpierw odczytaniu małej tabeli, a następnie wyszukaniu pasujących rekordów w dużej tabeli. Dodanie rekordów do tabeli może zmienić, która jest większa, a tym samym spowodować, że DBMS zmieni swój plan. Dlatego powinieneś spróbować wykonać EXPLAINS na bazie danych z realistycznymi danymi. Działanie z testową bazą danych z 5 rekordami w każdej tabeli ma znacznie mniejszą wartość niż działanie z działającą bazą danych.
Cóż, można powiedzieć o wiele więcej, ale nie chcę tutaj pisać książki.
