Lekcje modułu (3/4)
Indeksy złożone i częściowe
W poprzednich lekcjach omawialiśmy użycie indeksów dla liniowych zapytań DBMS (WHERE country = 'Italy'). A co w sytuacji, gdy szukamy na dwóch połączonych frontach?
Na przykład w prawdziwym handlu elektronicznym możemy chcieć znaleźć zamówienia należące do określonego identyfikatora klienta ORAZ mieszczące się w określonym przedziale czasu: KODPH0.
Jeśli masz tylko indeks bazowy na customer_id, Postgres szybko znajdzie 50 zamówień klienta, korzystając z drzewa binarnego, ale następnie musi ręcznie i sekwencyjnie przeglądać wszystkie 50 z nich, leniwie filtrując daty wzrokiem.
Indeksy złożone
Możemy powiedzieć systemowi DBMS, aby uporządkował pliki „słownika analitycznego” nie według jednego kluczowego wymiaru, ale według kilku.
CREATE INDEX idx_orders_customer_date ON orders(customer_id, placed_at);Indeks „złożony” traktuje kolejność swoich parametrów jako bardzo ważną: tutaj węzły B-Tree grupują i sztywno kategoryzują customer_id w bloku (najbardziej rozróżniającym pod względem separacji); wewnątrz nich znajduje się poddrzewo rozgałęziające się z różnymi wartościami czasu placed_at w doskonale posortowanym porządku.
Ta struktura brutalnie unicestwia klauzule WHERE z wieloma zagnieżdżonymi predykatami.
Indeksy częściowe (indeksy filtrowane)
Każdy indeks kosztuje miejsce na dysku i procesor w strumieniach wejściowych użytkownika. Co by było, gdyby handel elektroniczny wymagał ciągłego sortowania i wyszukiwania filtra, ale tylko dla niewielkiej liczby rekordów? (Na przykład: szybkie sprawdzanie nieprzeczytanych powiadomień.) Tworzenie indeksu „is_read” dla wszystkich 10 000 000 powiadomień jest niezwykle nudne, jeśli „Nieprzeczytane” reprezentuje tylko 5 z nich.
CREATE INDEX idx_unread_notifs ON notifications(user_id)
WHERE is_read = false; -- Questa aggiuntiva è l'"Indice Parziale"Baza danych zbuduje błyskawiczne drzewo B, które przechowuje klucze szybkiego dostępu do bazy danych TYLKO, jeśli rekord jest nieprzeczytany! Dysk pokocha indeks składający się z 5 wierszy (3 bajty) zamiast jednego z 10 milionami. Szybkie SELECTy w pełni czerpią korzyści:
KODPH0
Twoja kolej
Chcemy zoptymalizować wyszukiwanie haseł tymczasowych / tokenów resetowania. Bardzo często wykonujemy wywołania SELECT w poszukiwaniu wszystkich klientów zarejestrowanych z określonego kraju w połączeniu ze znanym miastem. Utwórz złożony indeks o nazwie „idx_cust_loc” dla „klientów”. Najpierw przekaż pole „kraj” (które jest bardziej ekskluzywne), a następnie pole „miasto”.
Pokaż wskazówkę
Składnia: CREATE INDEX nazwa ON tabela(kol1, kol2);
Rozwiązanie dostępne po 3 próbach
Eksploracja indeksów warunkowych (częściowych).
Zoptymalizuj wyszukiwanie użytkowników podczas zakupów: użytkownicy rejestrują się wstępnie, ale my musimy jedynie umieścić ich na liście w chronologicznej kolejności rejestracji (utwórz indeks na „signed_up_on” w „klientach”), ale OGRANICZONE TYLKO do klientów z dokładnie pełnego „miasta”: „Milano”.
Pokaż wskazówkę
Jest ona deklarowana normalnie we właściwości target; na koniec dodajesz magiczne słowo kluczowe WHERE city = 'Milano'.
Rozwiązanie dostępne po 3 próbach