Sulla base della specifica incompleta, farei questo:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Questo indice soddisferebbe il requisito di un indice con storeid come colonna principale. (E sappiamo che avrà quel requisito se questo è InnoDB e storeid è una chiave esterna.)
Con una riga di tabella così breve, andrei avanti e ne farei un indice di copertura e includerò tutte le colonne. Quindi le query possono essere soddisfatte direttamente dalle pagine di indice senza cercare le pagine di dati nella tabella sottostante.
Dal momento che sappiamo che (seedid,storeid) è unico (dato come CHIAVE PRIMARIA), conosciamo (storeid,seedid) è anche unico, quindi potremmo anche dichiarare l'indice UNICO.
Ci sono altre scelte; non dobbiamo creare quell'indice sopra. Potremmo semplicemente fare questo invece:
CREATE INDEX stock_IX2 ON stock (storeid)
Ma ciò utilizzerà quasi la stessa quantità di spazio e non sarà così vantaggioso per quante più query possibili.
L'indice secondario conterrà la chiave primaria della tabella; in modo che il secondo indice includa il seedid colonna, data la CHIAVE PRIMARIA della tabella. Cioè, l'indice è equivalente a questo:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
E sappiamo che la combinazione di queste due colonne è unica, quindi possiamo includere la parola chiave UNICA
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Se facciamo un EXPLAIN su una query del modulo
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
è probabile che vedremo un'operazione di scansione dell'intervallo sull'indice secondario; ma recuperando il valore di stk colonna richiederà la ricerca delle pagine di dati nella tabella sottostante. Compreso il stk colonna nell'indice secondario renderà l'indice una copertura indice per la query. Con l'indice consigliato per primo nella risposta, ci aspettiamo il EXPLAIN output per mostrare "Uso dell'indice".
