Baserat på den ofullständiga specifikationen skulle jag göra så här:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Detta index skulle uppfylla kravet på ett index med storeid
som ledande kolumn. (Och vi vet kommer att ha det kravet om detta är InnoDB och storeid
är en främmande nyckel.)
Med en så kort tabellrad skulle jag gå vidare och göra den till ett täckande index och inkludera alla kolumner. Då kan frågor tillfredsställas direkt från indexsidorna utan uppslag till datasidor i den underliggande tabellen.
Eftersom vi vet att (seedid,storeid)
är unik (given som PRIMÄRKEY), vi vet (storeid,seedid)
är också unikt, så vi kan lika gärna förklara indexet som UNIKT.
Det finns andra val; vi behöver inte skapa det indexet ovan. Vi kunde bara göra det här istället:
CREATE INDEX stock_IX2 ON stock (storeid)
Men det kommer att använda nästan samma mängd utrymme och inte vara lika fördelaktigt för så många möjliga frågor.
Det sekundära indexet kommer att innehålla tabellens primärnyckel; så att det andra indexet kommer att innehålla seedid
kolumn, givet den PRIMÄRA KEY i tabellen. Det vill säga, indexet motsvarar detta:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
Och vi vet att kombinationen av dessa två kolumner är unik, så vi kan inkludera nyckelordet UNIQUE
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Om vi gör en EXPLAIN på en fråga av formuläret
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
vi kommer sannolikt att se en intervallavsökningsoperation på det sekundära indexet; men hämtar värdet på stk
kolumnen kommer att kräva uppslag till datasidorna i den underliggande tabellen. Inklusive stk
kolumnen i det sekundära indexet kommer att göra indexet till ett täckande index för frågan. Med det index som först rekommenderas i svaret förväntar vi oss EXPLAIN
ut för att visa "Använder index".