Com base na especificação incompleta, eu faria isso:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Este índice satisfaria o requisito para um índice com
storeid como coluna principal. (E sabemos que terá esse requisito se for InnoDB e storeid é uma chave estrangeira.) Com uma linha de tabela tão curta, eu faria um índice de cobertura e incluiria todas as colunas. Em seguida, as consultas podem ser atendidas diretamente das páginas de índice sem pesquisas para páginas de dados na tabela subjacente.
Como sabemos que
(seedid,storeid) é único (dado como a CHAVE PRIMÁRIA), sabemos (storeid,seedid) também é único, então podemos declarar o índice como UNIQUE. Existem outras opções; não precisamos criar esse índice acima. Poderíamos apenas fazer isso em vez disso:
CREATE INDEX stock_IX2 ON stock (storeid)
Mas isso usará quase a mesma quantidade de espaço e não será tão benéfico para tantas consultas possíveis.
O índice secundário conterá a chave primária da tabela; para que o segundo índice inclua o
seedid coluna, dada a PRIMARY KEY da tabela. Ou seja, o índice é equivalente a isso: CREATE INDEX stock_IX3 ON stock (storeid,seedid)
E sabemos que a combinação dessas duas colunas é única, então podemos incluir a palavra-chave UNIQUE
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Se fizermos um EXPLAIN em uma consulta do formulário
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
provavelmente veremos uma operação de varredura de intervalo no índice secundário; mas recuperando o valor de
stk coluna exigirá a pesquisa das páginas de dados na tabela subjacente. Incluindo o stk coluna no índice secundário tornará o índice uma cobertura índice para a consulta. Com o índice recomendado pela primeira vez na resposta, esperamos que o EXPLAIN saída para mostrar "Usando índice". 
