Ogólnie moja strategia indeksowania wyglądałaby mniej więcej tak (na razie używam wyłącznie SQL Server - w razie potrzeby dostosuj do własnego systemu bazy danych):
-
wybierz dobre klucz klastrowy - nie GUID, nie
VARCHAR(250)
czy coś - dobre klucz klastrowania jest wąski, unikalny, stabilny, stale rosnący - coś w rodzajuINT IDENTITY
jest perfekcyjnie. Sprawia, że jest to klucz podstawowy klastra -> daje pierwszy indeks w tabeli -
dla każdej kolumny, która jest używana jako klucz obcy do innej tabeli - dodaj indeks. Może to być indeks jednokolumnowy – lub indeks złożony – cokolwiek działa najlepiej w Twoim przypadku. Ważne jest, aby kolumna klucza obcego była pierwszą kolumna w tym indeksie (jeśli używasz indeksu złożonego) - w przeciwnym razie korzyści dla
JOIN
lub w celu sprawdzenia integralności referencyjnej nie będą dostępne dla Twojego systemu
I na razie to wszystko.
Następnie:uruchom swój system - obserwuj i mierz - ustal punkt odniesienia. Czy aplikacja jest wystarczająco szybka? Jeśli tak -> gotowe - idź do domu i ciesz się wolnym czasem.
Jeśli nie:zacznij zbierać dane i wskazówki, dlaczego aplikacja nie jest wystarczająco szybka. Spójrz m.in. rzeczy takie jak DMV w SQL Server, które informują o najgorzej wydajnych zapytaniach lub brakujący indeks DMV . Przeanalizuj je. Zobacz, co możesz poprawić. Dodaj jeden indeks na raz i znowu:obserwuj, mierz, porównuj ze swoją linią bazową.
Jeśli masz poprawę -> pozostaw ten wskaźnik na miejscu, a ten pomiar będzie twoją nową linią odniesienia. Opłucz i powtarzaj, aż Ty (i Twoi użytkownicy) będziesz zadowolony z działania aplikacji (i wtedy idź do domu i ciesz się wolnym czasem).
Nadmierne indeksowanie w SQL Server może być gorsze niż brak indeksów. Nie zaczynaj od zbyt wielu indeksów! Tylko ustalaj dobre klastrowane indeksy PK i nieklastrowane indeksy kluczy obcych - to wszystko - a następnie obserwuj, mierz, optymalizuj i powtarzaj ten cykl.