Op basis van de onvolledige specificatie zou ik dit doen:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Deze index zou voldoen aan de eis voor een index met storeid
als de leidende kolom. (En we weten dat deze vereiste zal gelden als dit InnoDB en storeid
is is een externe sleutel.)
Met zo'n korte tabelrij zou ik er een dekkende index van maken en alle kolommen opnemen. Dan kunnen zoekopdrachten direct worden uitgevoerd vanaf de indexpagina's zonder opzoekingen naar gegevenspagina's in de onderliggende tabel.
Omdat we weten dat (seedid,storeid)
uniek is (gegeven als de PRIMAIRE SLEUTEL), we kennen (storeid,seedid)
is ook uniek, dus we kunnen de index net zo goed als UNIEK verklaren.
Er zijn andere keuzes; we hoeven die index hierboven niet te maken. We zouden in plaats daarvan dit kunnen doen:
CREATE INDEX stock_IX2 ON stock (storeid)
Maar dat zal bijna dezelfde hoeveelheid ruimte in beslag nemen en niet zo gunstig zijn voor zoveel mogelijk vragen.
De secundaire index bevat de primaire sleutel van de tabel; zodat de tweede index de seedid
. zal bevatten kolom, gegeven de PRIMARY KEY van de tabel. Dat wil zeggen, de index is gelijk aan dit:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
En we weten dat de combinatie van die twee kolommen uniek is, dus we kunnen het UNIQUE trefwoord
. opnemen CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Als we een EXPLAIN doen op een vraag van het formulier
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
we zullen waarschijnlijk een bereikscanbewerking zien op de secundaire index; maar het ophalen van de waarde van stk
kolom vereist het opzoeken van de gegevenspagina's in de onderliggende tabel. Inclusief de stk
kolom in de secundaire index maakt de index een bedekkende index voor de zoekopdracht. Met de index als eerste aanbevolen in het antwoord, verwachten we de EXPLAIN
uitvoer om "Index gebruiken" weer te geven.