@Pierre 303 już to powiedział, ale powiem to jeszcze raz. NALEŻY używać indeksów dla kombinacji kolumn. Indeks łączony (a, b)jest tylko nieco wolniejszy w przypadku zapytań aniż sam indeks ai jest znacznie lepszy, jeśli zapytanie łączy obie kolumny. Niektóre bazy danych mogą dołączać indeksy przed ai bpo uderzeniu w tabelę, ale nie jest to tak dobre, jak posiadanie połączonego indeksu. Podczas tworzenia indeksu łączonego należy umieścić kolumnę, która najprawdopodobniej zostanie przeszukana jako pierwsza w indeksie łączonym.
Jeśli baza danych obsługuje tę funkcję, DO umieszczaj indeksy na funkcjach wyświetlanych w zapytaniach, a nie w kolumnach. (Jeśli wywołujesz funkcję w kolumnie, indeksy w tej kolumnie są bezużyteczne).
Jeśli używasz bazy danych z prawdziwych tabel tymczasowych, które można tworzyć i niszczyć w locie (np PostgreSQL, MySQL, ale nie Oracle), a następnie NIE tworzyć indeksy na tabelach tymczasowych.
Jeśli używasz bazy danych, która pozwala na to (np Oracle), DO zamek w dobrych planów kwerend. Optymalizatory zapytań z czasem zmienią plany zapytań. Zwykle poprawiają plan. Ale czasami robią to znacznie gorzej. Na ogół tak naprawdę nie zauważysz ulepszeń planu - zapytanie nie było wąskim gardłem. Ale jeden zły plan może zniszczyć ruchliwą witrynę.
NIE mają indeksów na tabelach, na których zamierzasz wykonać duże ładowanie danych. Znacznie, znacznie szybciej jest upuszczać indeksy, ładować dane, a następnie odbudowywać indeksy, niż utrzymywać je podczas ładowania tabeli.
NIE używaj indeksów do zapytań, które mają dostęp do więcej niż niewielkiej części dużej tabeli. (Jak mały zależy od sprzętu. 5% to przyzwoita zasada.) Na przykład, jeśli masz dane z nazwiskami i płcią, nazwiska są dobrym kandydatem do indeksowania, ponieważ dowolna nazwa reprezentuje niewielki ułamek wszystkich wierszy. Indeksowanie według płci nie byłoby pomocne, ponieważ nadal będziesz mieć dostęp do 50% wierszy. Naprawdę chcesz zamiast tego użyć pełnego skanowania tabeli. Powodem jest to, że indeksy kończą losowy dostęp do dużego pliku, co powoduje, że potrzebujesz operacji na dysku. Wyszukiwanie dysku trwa powoli. Na przykład ostatnio udało mi się przyspieszyć godzinne zapytanie, które wyglądało następująco:
SELECT small_table.id, SUM(big_table.some_value)
FROM small_table
JOIN big_table
ON big_table.small_table_id = small_table.id
GROUP BY small_table.id
poniżej 3 minut, przepisując go w następujący sposób:
SELECT small_table.id, big_table_summary.summed_value
FROM small_table
JOIN (
SELECT small_table_id, SUM(some_value) as summed_value
FROM big_table
GROUP BY small_table_id
) big_table_summary
ON big_table_summary.small_table_id = small_table.id
co zmusiło bazę danych do zrozumienia, że nie powinna próbować używać kuszącego indeksu big_table.small_table_id. (Dobra baza danych, taka jak Oracle, powinna to sobie wyobrazić. To zapytanie działało na MySQL.)
Aktualizacja: Oto wyjaśnienie punktu poszukiwania dysku, który zrobiłem. Indeks umożliwia szybkie sprawdzenie, gdzie znajdują się dane w tabeli. Zwykle jest to wygrana, ponieważ będziesz patrzeć tylko na te dane, na które musisz spojrzeć. Ale nie zawsze, szczególnie jeśli w końcu spojrzysz na wiele danych. Dyski dobrze przesyłają strumieniowo dane, ale spowalniają wyszukiwania. Losowe wyszukiwanie danych na dysku zajmuje 1/200 sekundy. Powolna wersja zapytania zakończyła się zrobieniem około 600 000 z nich i zajęła prawie godzinę. (Przeprowadzono więcej wyszukiwań niż to, ale niektóre z nich przechwyciły buforowanie). Natomiast szybka wersja wiedziała, że musi wszystko przeczytać i przesyłać strumieniowo dane z prędkością około 70 MB / sekundę. Przeszedł przez stół 11 GB w niecałe 3 minuty.