Исходя из неполной спецификации, я бы сделал это:
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
покажет «Использование индекса».