Basado en la especificación incompleta, haría esto:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Este índice cumpliría el requisito de un índice con storeid como columna principal. (Y sabemos que tendrá ese requisito si se trata de InnoDB y storeid es una clave foránea.)
Con una fila de tabla tan corta, continuaría y la convertiría en un índice de cobertura e incluiría todas las columnas. Luego, las consultas se pueden satisfacer directamente desde las páginas de índice sin búsquedas en las páginas de datos en la tabla subyacente.
Como sabemos que (seedid,storeid) es único (dado como PRIMARY KEY), conocemos (storeid,seedid) también es único, por lo que también podríamos declarar el índice como ÚNICO.
Hay otras opciones; no tenemos que crear ese índice arriba. Podríamos hacer esto en su lugar:
CREATE INDEX stock_IX2 ON stock (storeid)
Pero eso usará casi la misma cantidad de espacio y no será tan beneficioso para tantas consultas posibles.
El índice secundario contendrá la clave principal de la tabla; para que el segundo índice incluya el seedid columna, dada la CLAVE PRINCIPAL de la tabla. Es decir, el índice es equivalente a esto:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
Y sabemos que la combinación de esas dos columnas es única, por lo que podemos incluir la palabra clave ÚNICA
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Si hacemos un EXPLAIN sobre una consulta del formulario
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
es probable que veamos una operación de escaneo de rango en el índice secundario; pero recuperando el valor de stk la columna requerirá la búsqueda de las páginas de datos en la tabla subyacente. Incluyendo el stk columna en el índice secundario hará que el índice sea una cobertura índice de la consulta. Con el índice recomendado primero en la respuesta, esperamos el EXPLAIN salida para mostrar "Usando el índice".
