Na podstawie niepełnej specyfikacji zrobiłbym to:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Ten indeks spełniałby wymagania dla indeksu z storeid jako wiodąca kolumna. (I wiemy, że będzie to wymaganie, jeśli jest to InnoDB i storeid jest kluczem obcym.)
Mając tak krótki wiersz tabeli, zrobiłbym z niego indeks pokrywający i zawierał wszystkie kolumny. Następnie zapytania mogą być realizowane bezpośrednio ze stron indeksowych bez przeszukiwania stron danych w tabeli bazowej.
Ponieważ wiemy, że (seedid,storeid) jest unikalny (podany jako KLUCZ PODSTAWOWY), znamy (storeid,seedid) jest również unikalny, więc równie dobrze możemy zadeklarować indeks jako UNIQUE.
Istnieją inne możliwości; nie musimy tworzyć tego indeksu powyżej. Zamiast tego moglibyśmy zrobić to:
CREATE INDEX stock_IX2 ON stock (storeid)
Ale to zajmie prawie taką samą ilość miejsca i nie będzie tak korzystne dla wielu możliwych zapytań.
Indeks pomocniczy będzie zawierał klucz podstawowy tabeli; aby drugi indeks zawierał seedid kolumny, biorąc pod uwagę KLUCZ PODSTAWOWY tabeli. Oznacza to, że indeks jest odpowiednikiem tego:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
Wiemy, że połączenie tych dwóch kolumn jest niepowtarzalne, dlatego możemy dołączyć słowo kluczowe UNIKALNE
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Jeśli zrobimy WYJAŚNIENIE na zapytanie w formularzu
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
prawdopodobnie zobaczymy operację skanowania zakresu na indeksie wtórnym; ale pobieranie wartości stk kolumna będzie wymagała wyszukania stron danych w tabeli źródłowej. W tym stk kolumna w indeksie wtórnym sprawi, że indeks będzie zakrywającym indeks zapytania. Z indeksem zalecanym jako pierwszy w odpowiedzi, oczekujemy, że EXPLAIN wyjście, aby pokazać "Korzystanie z indeksu".
