Prawidłowo – kluczem do przyspieszenia wyszukiwania i sortowania w relacyjnej bazie danych jest utworzenie indeksu na kolumnach, po których najczęściej filtrujesz (WHERE), łączysz tabele (JOIN) albo sortujesz (ORDER BY). Indeks działa podobnie jak spis treści czy indeks na końcu książki – zamiast przeglądać każdą stronę po kolei, silnik bazy danych korzysta z dodatkowej struktury danych (najczęściej drzewa B-drzewiastego, tzw. B-tree), żeby bardzo szybko znaleźć interesujące wiersze. W praktyce oznacza to, że zapytania, które wcześniej skanowały całą tabelę (full table scan), zaczynają wykorzystywać indeks, co drastycznie zmniejsza liczbę odczytanych stron danych z dysku. W SQL jest to standardowa dobra praktyka: dla kolumn używanych w warunkach wyszukiwania i sortowania tworzy się indeksy, ale z umiarem, żeby nie przesadzić. Z mojego doświadczenia w projektach webowych typowe indeksy to np. indeks na kolumnie email w tabeli użytkowników, indeks na data_dodania w tabeli z artykułami albo indeks złożony (wielokolumnowy) na (user_id, created_at) w tabeli logów czy zamówień. Dzięki temu zapytania typu SELECT * FROM zamowienia WHERE user_id = ? ORDER BY created_at DESC działają bardzo szybko. Warto też wiedzieć, że dobry administrator lub programista zawsze sprawdza plany wykonania zapytań (EXPLAIN w MySQL/PostgreSQL) i na tej podstawie decyduje, które indeksy są naprawdę potrzebne. Tworzenie indeksów na oślep nie jest najlepszym pomysłem, ale sensowne indeksowanie jest absolutnym standardem w profesjonalnych systemach bazodanowych i jedną z podstawowych technik optymalizacji wydajności.
W tym pytaniu chodzi o przyspieszenie operacji wyszukiwania i sortowania, czyli stricte o wydajność wykonywania zapytań SELECT. Bardzo łatwo jest tu pomylić pojęcia z projektowania relacyjnych baz danych i sięgnąć po rozwiązania, które są ważne, ale rozwiązują inne problemy niż wydajność zapytań. Klucz obcy jest mechanizmem służącym do utrzymania spójności między tabelami. Określa on, że wartość w jednej tabeli musi odpowiadać istniejącemu rekordowi w innej tabeli. To świetne narzędzie do pilnowania integralności referencyjnej, ale samo dodanie klucza obcego nie przyspiesza wyszukiwania po dowolnej kolumnie. Co prawda silniki baz danych często automatycznie tworzą indeks na kolumnie będącej kluczem głównym, a czasem również na kluczu obcym, ale sednem optymalizacji jest właśnie indeks, nie sam fakt istnienia klucza obcego. Kolejna sprawa to więzy integralności, czyli różnego rodzaju ograniczenia typu NOT NULL, UNIQUE, CHECK czy wspomniane klucze obce. One pomagają w utrzymaniu poprawności danych, zapobiegają wprowadzaniu bzdurnych rekordów, ale nie są mechanizmem projektowanym z myślą o przyspieszaniu sortowania czy filtrowania. Można powiedzieć, że dbają o jakość danych, a nie o szybkość ich wyszukiwania. Ostatnia koncepcja, czyli tworzenie osobnej tabeli zawierającej tylko często wyszukiwane pola, to typowy przykład nadmiernej normalizacji albo wręcz niewłaściwej denormalizacji. Taki zabieg zazwyczaj zwiększa złożoność systemu, utrudnia zapytania (potrzeba dodatkowych JOIN-ów) i wcale nie gwarantuje lepszej wydajności. Bez indeksów na odpowiednich kolumnach nowa tabela dalej będzie skanowana w całości. Typowy błąd myślowy polega tu na założeniu, że „mniej kolumn = szybsze zapytania”, co w praktyce nie jest prawdą, jeśli baza i tak musi przeszukać każdy wiersz. Standardowa, sprawdzona w branży metoda to dobrze zaprojektowane indeksy, a nie mnożenie tabel czy ślepe dokładanie więzów integralności w nadziei na przyspieszenie bazy.