Въз основа на непълната спецификация бих направил това:
CREATE UNIQUE INDEX stock_UX1 ON stock (storeid,seedid,stk)
Този индекс ще удовлетвори изискването за индекс с storeid
като водеща колона. (И знаем, че ще има това изискване, ако това е InnoDB и storeid
е външен ключ.)
С такъв кратък ред на таблица бих го направил покриващ индекс и ще включа всички колони. След това заявките могат да бъдат удовлетворявани директно от индексните страници без търсене на страници с данни в основната таблица.
Тъй като знаем, че (seedid,storeid)
е уникален (даден като ОСНОВЕН КЛЮЧ), знаем (storeid,seedid)
също е уникален, така че можем да декларираме индекса като УНИКАЛЕН.
Има и други възможности за избор; не е нужно да създаваме този индекс по-горе. Вместо това можем да направим това:
CREATE INDEX stock_IX2 ON stock (storeid)
Но това ще използва почти същото количество пространство и няма да бъде толкова полезно за толкова много възможни заявки.
Вторичният индекс ще съдържа първичния ключ на таблицата; така че вторият индекс ще включва seedid
колона, дадена ПЪРВИЧНИЯТ КЛЮЧ на таблицата. Тоест, индексът е еквивалентен на това:
CREATE INDEX stock_IX3 ON stock (storeid,seedid)
И знаем, че комбинацията от тези две колони е уникална, така че можем да включим ключовата дума UNIQUE
CREATE UNIQUE INDEX stock_UX4 ON stock (storeid,seedid)
Ако направим ОБЯСНЕНИЕ на заявка от формата
EXPLAIN
SELECT t.storeid
, t.seedid
, t.stk
FROM stock t
WHERE t.storeid = 'foo'
вероятно ще видим операция за сканиране на диапазон на вторичния индекс; но извличане на стойността на stk
ще изисква търсене на страниците с данни в основната таблица. Включително stk
колона във вторичния индекс ще направи индекса покриващ индекс за заявката. С индекса, препоръчан първи в отговора, очакваме EXPLAIN
изход, за да покаже „Използване на индекс“.