Baza sklepu bez indeksów: każdy filtr i JOIN schodził do pełnego skanu, aż właściwe indeksy dały mikrosekundy

To, że indeks przyspiesza zapytanie, nie jest ciekawe. Ciekawe jest, kiedy indeks istnieje i nie pomaga, oraz jak czytać plan, żeby to zobaczyć.

„Użyty indeks” to nie to samo co szybko

Plan pokazuje nazwę klucza nawet wtedy, gdy baza czyta cały indeks. Kolumną do czytania jest typ dostępu: ref, eq_ref i range to wyszukanie przez indeks, index to pełny skan indeksu, ALL to pełny skan tabeli. Plan potrafi podać nazwę klucza i zgłosić Using index, a pod spodem i tak czytać milion wpisów. Nazwa klucza nie jest dowodem; dowodem są typ dostępu i liczba wierszy.

Indeks istnieje, a baza go ignoruje

Na kolumnie statusu, pięć różnych wartości, założyliśmy indeks, a suma wartości opłaconych zamówień i tak wykonała pełny skan tabeli: 500 000 wierszy, 35,7 ms. To nie błąd optymalizatora, tylko decyzja: opłacone zamówienia to 20 procent tabeli, a kwota nie jest w indeksie, więc użycie indeksu oznaczałoby 100 000 losowych doskoków po wiersze, a to kosztuje więcej niż jeden sekwencyjny skan. Indeks na kolumnie o niewielu różnych wartościach często niczego nie zmienia.

Funkcja na kolumnie wyłącza indeks

Mając indeks na dacie zamówienia, dwa zapytania o ten sam dzień zachowują się zupełnie inaczej. Warunek z datą opakowaną funkcją czyta cały indeks, 500 000 wpisów, 32,7 ms. Warunek jako zakres od północy do północy czyta 556 wierszy w 0,073 ms. Różnica około 447 razy bierze się wyłącznie z funkcji wokół kolumny:

WHERE DATE(created_at) = '2026-06-15'                              pełny skan indeksu
WHERE created_at >= '2026-06-15' AND created_at < '2026-06-16'      wyszukanie zakresu

Opakowanie indeksowanej kolumny czymkolwiek, funkcją, konkatenacją, rzutowaniem, odbiera bazie wyszukanie po zakresie. Regułę pisze się po stronie wartości, nie kolumny.

Niejawna konwersja typu: zły wynik, i to wolniej

Najgroźniejsza pułapka, bo uderza w poprawność, nie tylko w szybkość. Kolumna statusu jest tekstowa. Porównana z wartością tekstową zwraca 100 000 wierszy w 8,5 ms przez indeks. Porównana z liczbą 0 zamiast tekstu zwraca wszystkie 500 000 wierszy w 84,6 ms pełnym skanem indeksu. MariaDB przy porównaniu rzutuje każdy tekst na liczbę, każdy status daje 0 i warunek pasuje do każdego wiersza. Zapytanie jest wolniejsze, zwraca zły wynik i zgłasza tylko ostrzeżenie, którego nikt nie czyta. Typy w warunku muszą się zgadzać.

Indeks złożony działa tylko od lewej

Indeks złożony na produkcie i ilości w pozycjach zamówień obsługuje warunek na produkt w 0,020 ms. Warunek na samą ilość nie może z niego skorzystać do wyszukania i skanuje cały indeks, 1,75 miliona wpisów, 96,1 ms. Indeks wielokolumnowy obsługuje warunki tylko od swojej lewej krawędzi, więc kolejność kolumn jest decyzją projektową, dobraną do prawdziwych zapytań.

Indeks pokrywający usuwa doskoki po wiersze

Lista tysiąca najnowszych zamówień z numerem i kwotą: przy indeksie na samej dacie baza czyta indeks po kolei, ale po kwotę musi doskoczyć do każdego wiersza, 0,75 ms. Przy indeksie na dacie i kwocie wszystko, czego zapytanie potrzebuje, jest w indeksie, bez doskoków, 0,24 ms. Przy większych wynikach i zimnym cache różnica jest znacznie większa niż to trzykrotne przyspieszenie.