Накладные расходы композитных индексов

Question

У меня есть много таблиц, где у меня есть индексы на внешних ключах и кластерные индексы, которые включают эти внешние ключи. Например, у меня есть таблица вроде следующего:

TABLE: Item 
------------------------ 
id  PRIMARY KEY 
owner FOREIGN KEY 
status 

... many more columns 

MySQL создает индексы для первичных и внешних ключей, но иногда, я хочу, чтобы улучшить производительность запросов, так что я буду создавать кластерные или покрывающие индексы. Это приводит к наличию индексов с перекрывающимися столбцами.

INDEXES ON: Item 
------------------------ 
idx_owner (owner) 
idx_owner_status (owner, status) 

Если бы я упал idx_owner, будущие запросы, которые обычно используют idx_owner бы просто использовать idx_owner_status, поскольку она имеет owner как первый столбец в индексе.

Стоит ли поддерживать idx_owner вокруг? Есть ли дополнительные служебные данные ввода-вывода для использования idx_owner_status, хотя MySQL использует только часть индекса?

Редактировать: Меня действительно интересует только InnoDB ведет себя относительно индексов.

Answer 1

Короткие ответы Оставьте комментарий.

Long Anwser Вещи рассмотреть:

Брось:

• Каждый INDEX отдельный BTree, который находится на диске, поэтому она занимает пространство.
• Каждый INDEX обновляется (раньше или позже), когда вы INSERT новая строка или UPDATE изменяет индексированный столбец. Это занимает некоторое количество CPU и ввода-вывода и buffer_pool для «буфера изменений».
• Любое Функциональное использование (в отличие от производительности) для более короткого индекса может быть выполнено более длинным.

Не бросайте его:

• Чем больше индекс объемнее, чем покороче. Таким образом, он менее кэшируемый. Поэтому (в экстремальных ситуациях), используя более громоздкий, вместо более короткого может вызывать больше ввода-вывода. Дело, которое усугубляет это: INDEX(int, varchar255).

Очень редко, что последний элемент действительно переопределяет другие предметы. Индекс

Bonus

А "покрытие" это тот, который содержит все столбцы, указанные в SELECT.Например:

SELECT status FROM tbl WHERE owner = 123; 

Это будет касаться только в ВТКЕЕ для INDEX(owner, status), таким образом, будучи заметно быстрее, чем

SELECT status, foo FROM tbl WHERE owner = 123; 

Если вам действительно нужен этот запрос, чтобы быть быстрее, а затем заменить как из вашего индексы с INDEX(owner, status, foo).

PK в Вторичном ключе

еще один лакомый ... В InnoDB, столбцы PRIMARY KEY неявно добавляются к каждому вторичному ключу. Таким образом, три примера действительно

INDEX(owner, id) 
INDEX(owner, status, id) 
INDEX(owner, status, foo, id) 

Более дискуссионной в своих блогах на composite indexes и index cookbook.