Когда индекс (в СУБД) является плохим индексом? - PullRequest
10 голосов
/ 14 мая 2009

Может кто-нибудь сказать мне, когда индекс является плохим индексом?

Ответы [ 8 ]

11 голосов
/ 14 мая 2009

Одно обстоятельство, при котором индекс в значительной степени безоговорочно плох, - это если есть другой индекс, который использует те же столбцы (в том же порядке ), что и префикс:

CREATE INDEX ix_good ON SomeTable(Col1, Col2, Col3);
CREATE INDEX ix_bad  ON SomeTable(Col1, Col2);

Плохой индекс - пустая трата дискового пространства, замедляющая операции модификации, которые не приносят никакой пользы.

11 голосов
/ 14 мая 2009

Если по индексируемому столбцу никогда не выполняется поиск, и таблица сильно обновляется, вы не получаете преимущества производительности, для которой нужны индексы. Напротив, вы можете пострадать от снижения производительности.

9 голосов
/ 14 мая 2009

Я связывался с ним раньше, и я буду ссылаться на него снова, потому что он превосходен:

Индексирование SQL за 9 с половиной минут, автор Stephane Faroult.

5 голосов
/ 14 мая 2009

Одна важная вещь, которую следует иметь в виду при использовании индексов (помимо вышеупомянутой части «фактического использования»), это понятие селективности.

При создании индексов вы хотите создать индексы для столбцов, которые имеют хорошие шансы на «высокую селективность». Это требует некоторого понимания данных в столбце (которые вы можете иметь или не иметь в зависимости от ваших знаний о домене / доступности образцов данных).

Селективность = количество различных значений / общее количество строк

Позволяет использовать таблицу «Люди» со столбцами для имени, фамилии, пола, возраста

Например, создание индекса для столбца, такого как Gender (где пол ограничен до NULL, M или F), не даст большого преимущества во время запроса (особенно если запрос уже приводит к сканированию таблицы по другим причинам) , В любом случае селективность этого индекса будет чрезвычайно низкой. В зависимости от СУБД использование этого индекса может фактически быть хуже, чем полное сканирование таблицы.

Однако создание составного индекса для (Given_name, Surname) обеспечит преимущества при выполнении запросов к этим столбцам. Селективность этого индекса (для большинства групп населения) была бы довольно хорошей.

Индекс с селективностью 1 является идеальным, однако единственный способ достичь селективности 1 - это иметь уникальный индекс для столбца, который не может быть равен нулю.

Также имейте в виду, что вы можете легко писать запросы, чтобы «отслеживать» ваши индексы и их избирательность.

1 голос
/ 14 мая 2009

Индекс плох, если вы никогда не выполняете поиск по нему. Например, индекс (Col1, Col2, Col3) - пустая трата ресурсов, если вы никогда не выполняете поиск по Col1, Col2 и Col3 в одном запросе.

1 голос
/ 14 мая 2009

Из-за наличия индексов наблюдается прирост производительности (создание и поддержание структуры). Вы обычно хотите, чтобы этот удар получал выгоду от более быстрого сканирования. Когда вы не получаете выгоды, это просто чистый убыток, и это плохой показатель.

Возможные причины:

  • Никогда не использованные индексы
  • Избыточные индексы
  • Таблицы, которые сканируются не очень часто, но постоянно обновляются (преимущество наличия индекса перевешивает преимущества, потому что таблица редко сканируется).
  • Таблицы, которые часто сканируются и постоянно обновляются. В этом случае вы можете получить выгоду как от индекса, так и от быстрого обновления / вставки, имея безиндексную таблицу для вставок / обновлений и таблицу с индексами для сканирований, которая обновляется ежедневно или ежечасно (в некоторых случаях это не так). не работает, конечно. Тогда вам нужно улучшить аппаратное обеспечение или переработать приложение, если в таком случае у вас возникнет серьезная проблема с производительностью).

Как найти свои плохие индексы? Большинство РСУБД имеют опции для отображения плана запроса, и вы можете увидеть, используются ли настроенные вами индексы так, как вы ожидаете. Это приводит меня к последнему совету: подумайте о своих индексах, никогда не создавайте их «на всякий случай».

1 голос
/ 14 мая 2009

Индекс должен помочь нам быстрее искать строки.

Если столбец индекса не используется для поиска , нет смысла его определять.

Если значения в этом столбце продолжают изменяться очень часто, это будет дополнительной работой для сервера базы данных (для переиндексации)

Если слишком много вставок и удалений из таблицы, это будет дополнительная работа для сервера

1 голос
/ 14 мая 2009

Если поле никогда не используется, это плохой показатель (если вы чувствуете, что ненужные вещи плохие.).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...