W celu przyśpieszenia operacji na bazie danych należy dla pól często wyszukiwanych lub sortowanych
A. stworzyć osobną tabelę przechowującą tylko te pola.
B. dodać klucz obcy.
C. utworzyć indeks.
D. dodać więzy integralności.
Pytanie z egzaminu CKE, styczeń 2016 (arkusz E.14-X-16.01).
Indeks jest właściwym mechanizmem do przyśpieszenia wyszukiwania i sortowania danych w tabeli. Działa trochę jak skorowidz w książce: baza nie musi czytać wszystkich rekordów po kolei, tylko może szybciej odnaleźć miejsce, w którym znajdują się potrzebne wartości. W praktyce indeksy zakłada się na kolumnach często używanych w warunkach WHERE, przy sortowaniu ORDER BY, grupowaniu GROUP BY oraz w połączeniach JOIN. Przykład: jeśli tabela klienci ma tysiące albo miliony rekordów i często szukamy po polu nazwisko, to indeks na tej kolumnie może mocno zmniejszyć czas zapytania. Typowa instrukcja SQL wygląda np. tak: CREATE INDEX idx_klienci_nazwisko ON klienci(nazwisko);. Z mojego doświadczenia indeksy są jedną z pierwszych rzeczy, które sprawdza się przy optymalizacji wolnych zapytań. Trzeba jednak pamiętać, że nie zakłada się ich bezmyślnie na każdej kolumnie. Indeksy zajmują miejsce na dysku i mogą spowolnić operacje INSERT, UPDATE oraz DELETE, bo struktura indeksu też musi być aktualizowana. Dobra praktyka branżowa to analizowanie planu zapytania, np. przez EXPLAIN, oraz tworzenie indeksów tam, gdzie realnie pomagają. Często stosuje się też indeksy złożone, np. na kilku kolumnach, jeśli zapytania regularnie filtrują dane według tego samego zestawu pól.
Przyśpieszanie wyszukiwania i sortowania w bazie danych nie polega na dokładaniu dowolnych elementów struktury tabeli. Klucz obcy ma zupełnie inne zadanie: opisuje relację między tabelami i pilnuje, żeby dane były spójne, na przykład żeby zamówienie wskazywało istniejącego klienta. Owszem, w wielu systemach kolumny używane jako klucze obce warto indeksować, bo biorą udział w JOIN-ach, ale sam fakt dodania klucza obcego nie jest ogólnym sposobem na szybsze wyszukiwanie po często filtrowanych polach. To częsty błąd myślowy: coś jest ważne w bazie, więc pewnie poprawia wydajność. Nie zawsze tak to działa. Więzy integralności, takie jak NOT NULL, UNIQUE, CHECK czy ograniczenia referencyjne, przede wszystkim chronią poprawność danych. Dzięki nim baza odrzuca niepoprawne rekordy, ale nie służą one bezpośrednio do optymalizacji sortowania. Czasem ograniczenie UNIQUE tworzy indeks techniczny, ale nie znaczy to, że dodawanie więzów integralności jest standardową odpowiedzią na problem wolnych zapytań. Tworzenie osobnej tabeli tylko z często używanymi polami też zwykle nie jest dobrym rozwiązaniem. Może prowadzić do duplikacji danych, trudniejszej synchronizacji i dodatkowych JOIN-ów, które nawet pogorszą wydajność. Denormalizacja bywa stosowana w dużych systemach raportowych, ale jest to świadoma decyzja projektowa, a nie podstawowa metoda przyśpieszania zwykłego wyszukiwania. W normalnej pracy z SQL najpierw analizuje się zapytania, sprawdza plan wykonania i dobiera indeksy do kolumn używanych w WHERE, ORDER BY, GROUP BY oraz JOIN. Moim zdaniem to jedna z tych rzeczy, które naprawdę odróżniają poprawnie zaprojektowaną bazę od takiej, która działa dobrze tylko na małej ilości danych.