Baseret på den ufuldstændige specifikation ville jeg gøre dette:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Dette indeks ville opfylde kravet om et indeks med storeid som den ledende kolonne. (Og vi ved vil have det krav, hvis dette er InnoDB og storeid er en fremmednøgle.)
Med så kort en tabelrække ville jeg gå videre og gøre den til et dækkende indeks og inkludere alle kolonnerne. Så kan forespørgsler opfyldes direkte fra indekssiderne uden opslag til datasider i den underliggende tabel.
Da vi ved det (seedid,storeid) er unik (angivet som PRIMÆR NØGLE), kender vi (storeid,seedid) er også unik, så vi kan lige så godt erklære indekset for at være UNIKT.
Der er andre valg; vi behøver ikke oprette det indeks ovenfor. Vi kunne bare gøre dette i stedet:
CREATE INDEX stock_IX2 ON stock (storeid)
Men det vil bruge næsten den samme mængde plads og ikke være så gavnligt for så mange mulige forespørgsler.
Det sekundære indeks vil indeholde tabellens primære nøgle; så det andet indeks vil inkludere seedid kolonne, givet den PRIMÆRE NØGLE i tabellen. Det vil sige, at indekset svarer til dette:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
Og vi ved, at kombinationen af disse to kolonner er unik, så vi kan inkludere nøgleordet UNIQUE
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Hvis vi laver en EXPLAIN på en forespørgsel i formen
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
vi vil sandsynligvis se en rækkeviddescanningsoperation på det sekundære indeks; men henter værdien af stk kolonne vil kræve opslag til datasiderne i den underliggende tabel. Herunder stk kolonne i det sekundære indeks vil gøre indekset til en dækkende indeks for forespørgslen. Med det indeks, der først anbefales i svaret, forventer vi EXPLAIN output for at vise "Using index".