Generator indeksu SQL

Generator indeksu SQL

Indeks SQL przyspiesza wyszukiwanie kosztem miejsca i wolniejszego zapisu. Dobrze dobrany indeks bywa różnicą między zapytaniem w milisekundach a trwającym sekundy. Generator składa polecenie CREATE INDEX dla MySQL, PostgreSQL lub SQLite, pilnuje ograniczeń wybranego silnika i od razu podaje polecenie cofnięcia (DROP INDEX) oraz zapytanie wyświetlające indeksy tabeli.

Rodzaje indeksów

Kolejność kolumn

W indeksie złożonym kolumny równościowe (np. user_id) dawaj przed zakresowymi (created_at). Zapytanie musi wykorzystywać prefiks indeksu, aby z niego skorzystać.

Przykład

Indeks na orders (user_id, created_at) przyspieszy zapytanie „zamówienia użytkownika posortowane po dacie”.

Jak działa generator indeksu SQL

Generator zamienia deklarację z formularza na gotową instrukcję DDL. Wybierasz silnik bazy (MySQL, PostgreSQL, SQLite albo tryb automatyczny), podajesz tabelę i kolumny po przecinku w wybranej kolejności, a po nazwie kolumny możesz dopisać ASC lub DESC. W opcjach zaawansowanych ustawiasz nazwę indeksu, metodę (BTREE, HASH, GIN, GIST), kolumny INCLUDE, warunek WHERE oraz przełączniki UNIQUE, IF NOT EXISTS i CONCURRENTLY. Podgląd odświeża się przy każdej zmianie, a sześć gotowych wzorców (złożony, unikalny, częściowy, sortowany, pokrywający, klucz obcy) wypełnia formularz jednym kliknięciem.

Tryb automatyczny generuje składnię MySQL, a na PostgreSQL przełącza się, gdy użyjesz opcji, których MySQL nie ma: GIN, GIST, WHERE, INCLUDE, CONCURRENTLY lub IF NOT EXISTS. Jeśli piszesz pod SQLite, wybierz go ręcznie. Gdy opcja nie pasuje do wybranego silnika, narzędzie zamiast polecenia pokazuje błąd przy polu, np. że MySQL nie obsługuje indeksów częściowych albo że w PostgreSQL indeks HASH obejmuje tylko jedną kolumnę.

Kolejność kolumn w nawiasie to kolejność sortowania w B-drzewie. Kolumna równościowa (np. user_id) zawęża zbiór do jednej wartości, a kolumna zakresowa lub sortowana (np. created_at) porządkuje wynik w obrębie tego zbioru. Odwrotna kolejność zwykle kończy się skanem całej tabeli albo sortowaniem po stronie silnika.

Składnia zależy od silnika. MySQL: CREATE [UNIQUE] INDEX `nazwa` ON `tabela` (kolumny) USING BTREE; — metoda stoi po liście kolumn, a nazwy są w odwrotnych apostrofach. PostgreSQL: CREATE [UNIQUE] INDEX [CONCURRENTLY] [IF NOT EXISTS] "nazwa" ON "tabela" USING metoda (kolumny) [INCLUDE (...)] [WHERE warunek];. SQLite nie pozwala wybrać metody, więc USING się nie pojawia. Jeśli nie podasz nazwy indeksu, narzędzie buduje ją według wzoru idx_tabela_kolumna_kolumna i zgłasza błąd, gdy przekroczy 63 znaki (limit w MySQL i PostgreSQL). Sprawdź też, czy nazwa nie koliduje z istniejącą w bazie.

Przykład krok po kroku

1. Dane wejściowe: tabela orders z 2 000 000 wierszy, kolumny user_id (BIGINT), created_at (timestamp), status (text). W bazie jest 50 000 użytkowników. Zapytanie brzmi: SELECT z tabeli orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 20.
2. W polu tabeli wpisujesz orders, a w polu kolumn: user_id, created_at DESC — najpierw kolumna z warunkiem równościowym, potem sortowana. Odwrotna kolejność nie obsłuży tego zapytania, bo created_at nie jest filtrowane.
3. Zostawiasz metodę BTREE, tryb zwykły i silnik automatyczny. Wynik (składnia MySQL): CREATE INDEX `idx_orders_user_id_created_at` ON `orders` (`user_id`, `created_at` DESC) USING BTREE; Nazwa ma 29 znaków. Narzędzie dopisuje uwagę, że MySQL przed wersją 8.0 ignoruje DESC w definicji indeksu.
4. Dodajesz INCLUDE: status, aby silnik mógł odczytać status bez sięgania do tabeli. Ponieważ MySQL nie zna INCLUDE, tryb automatyczny przechodzi na PostgreSQL: CREATE INDEX "idx_orders_user_id_created_at" ON "orders" USING BTREE ("user_id", "created_at" DESC) INCLUDE ("status"); Kolumna w INCLUDE nie zmienia kolejności klucza i nie służy do filtrowania. Przy ręcznie wybranym MySQL zobaczysz błąd z podpowiedzią, by dopisać kolumnę do klucza.
5. Liczysz zysk: bez indeksu silnik sprawdza 2 000 000 wierszy; z indeksem trafia w gałąź odpowiadającą jednemu user_id, czyli średnio 2 000 000 / 50 000 = 40 wierszy na użytkownika, a z LIMIT 20 odczytuje tylko pierwsze 20.
6. Szacujesz koszt miejsca: klucz to 8 B (BIGINT) + 8 B (timestamp) = 16 B na wiersz, czyli 2 000 000 × 16 B = 32 000 000 B ≈ 30,5 MiB samych danych klucza, plus narzut struktury B-drzewa i kolumna status z INCLUDE, których narzędzie nie liczy.

Opcje generatora i ich efekt w DDL

Praktyczne wskazówki

• Zacznij od zapytań, nie od kolumn. Wypisz wzorce WHERE, JOIN i ORDER BY, które faktycznie chodzą w aplikacji, i pod każdy z nich zaprojektuj osobny indeks. Indeks bez zapytania tylko zajmuje miejsce i spowalnia zapis.
• Nie powielaj prefiksów: indeks na kolumnach (user_id, created_at) obsłuży też zapytania filtrujące wyłącznie po user_id, więc osobny indeks na samym user_id jest zwykle zbędny.
• Ustal jedną konwencję nazw. Schemat typu idx_tabela_kolumna_kolumna ułatwia późniejsze wyszukanie i usunięcie indeksu oraz porównanie środowisk.
• Kolumny potrzebne tylko w SELECT wrzucaj do INCLUDE zamiast dopisywać je do klucza. Nie zmieniają sortowania i nie służą do filtrowania, ale mogą ograniczyć odczyty z tabeli.
• Na dużej tabeli w PostgreSQL włącz CONCURRENTLY. Takie polecenie nie działa wewnątrz transakcji (BEGIN … COMMIT), a gdy budowa się nie powiedzie, zostaje indeks oznaczony jako INVALID, który trzeba usunąć przed ponowną próbą.

Czego narzędzie nie uwzględnia

• Nie łączy się z bazą danych: nie sprawdzi, czy indeks już istnieje, czy nazwa jest wolna ani jakie typy mają kolumny. Przy GIN i GIST tylko ostrzega, że kolumna musi mieć odpowiedni typ (dla zwykłych typów bywa potrzebne rozszerzenie pg_trgm, btree_gin lub btree_gist).
• Nie analizuje planów zapytań, więc nie wie, czy silnik faktycznie użyje wygenerowanego indeksu. To potwierdza dopiero EXPLAIN (MySQL), EXPLAIN ANALYZE (PostgreSQL) lub EXPLAIN QUERY PLAN (SQLite) na realnych danych.
• Nie szacuje rozmiaru ani czasu budowy, bo nie zna liczby wierszy ani statystyk kolumn. Koszt miejsca i czas tworzenia indeksu sprawdzisz tylko po stronie bazy.
• Nie sprawdza składni warunku WHERE — odrzuca jedynie średnik, który oznaczałby drugie polecenie. Nie rozróżnia też wersji silnika: zgłasza ograniczenia MySQL, PostgreSQL i SQLite jako całości, a różnice między wersjami (np. DESC przed MySQL 8.0) podaje tylko jako uwagi.