Basierend auf der unvollständigen Spezifikation würde ich Folgendes tun:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Dieser Index würde die Anforderung für einen Index mit storeid erfüllen als Leitsäule. (Und wir wissen, dass diese Anforderung gelten wird, wenn dies InnoDB und storeid ist ist ein Fremdschlüssel.)
Bei einer so kurzen Tabellenzeile würde ich einen abdeckenden Index erstellen und alle Spalten einbeziehen. Dann können Abfragen direkt von den Indexseiten ohne Suchen nach Datenseiten in der zugrunde liegenden Tabelle erfüllt werden.
Da wir wissen, dass (seedid,storeid) eindeutig ist (angegeben als PRIMARY KEY), wissen wir (storeid,seedid) ist ebenfalls eindeutig, also können wir den Index genauso gut als EINZIGARTIG deklarieren.
Es gibt andere Möglichkeiten; wir müssen diesen Index oben nicht erstellen. Wir könnten stattdessen einfach Folgendes tun:
CREATE INDEX stock_IX2 ON stock (storeid)
Aber das wird fast den gleichen Speicherplatz beanspruchen und ist für so viele mögliche Abfragen nicht so vorteilhaft.
Der Sekundärindex enthält den Primärschlüssel der Tabelle; so dass der zweite Index den seedid enthält Spalte, gegeben der PRIMARY KEY der Tabelle. Das heißt, der Index entspricht dem:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
Und wir wissen, dass die Kombination dieser beiden Spalten eindeutig ist, also können wir das Schlüsselwort UNIQUE
einfügen CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Wenn wir ein EXPLAIN für eine Abfrage des Formulars
ausführen EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
wir werden wahrscheinlich einen Range-Scan-Vorgang auf dem sekundären Index sehen; aber den Wert von stk abrufen -Spalte erfordert eine Suche nach den Datenseiten in der zugrunde liegenden Tabelle. Einschließlich der stk Spalte im sekundären Index macht den Index zu einer Abdeckung Index für die Abfrage. Bei dem in der Antwort zuerst empfohlenen Index erwarten wir den EXPLAIN Ausgabe, um "Using index" anzuzeigen.
