Przejdź do głównej treści
eLearner.app
Moduł 10 · Lekcja 3 z 439/57 w kursie~12 min
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.

SQL
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.

SQL
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

Ćwiczenie#sql.m10.l3.e1
Próby: 0Ładowanie...

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”.

Ładowanie edytora...
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).

Ćwiczenie#sql.m10.l3.e2
Próby: 0Ładowanie...

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”.

Ładowanie edytora...
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