Как мне узнать, какие индексы создать для таблицы?

33

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

Ник Джинанто
источник
11
Есть. Попробуйте использовать, например, the-index-luke.com .
Дезсо
Ответ, который я видел больше всего, заключается в том, что вы должны индексировать первичные ключи и столбцы, которые вы используете в WHEREпредложениях.
Оскар Перссон
Пожалуйста, не делай этого. Первичный ключ определяет, как данные физически сортируются в таблице, и имеет свои собственные соображения. Вы должны очень тщательно выбирать первичный ключ, поскольку он также используется во всех других ваших индексах. См .: sqlskills.com/blogs/kimberly/…
Али Разеги
4
@AliRazeghi То (физическая сортировка) верно в определенных СУБД (при определенных обстоятельствах), а не в других. Например, это не так в PostgreSQL.
Дезсо
Голосование снова!
Али Разеги

Ответы:

29

Краткие правила. (Некоторые из них создаются автоматически, но могут быть позже удалены вручную, в зависимости от вашей базы данных. Не думайте, что вы всегда будете работать с PostgreSQL.)

  • Индексируйте каждый первичный ключ.
  • Индексируйте каждый внешний ключ.
  • Индексируйте каждый столбец, используемый в предложении JOIN.
  • Индексируйте каждый столбец, используемый в предложении WHERE.
  • Изучите свою документацию, чтобы узнать "эзотерические" параметры индексации, которые поддерживает ваша dbms.

Каждый первичный ключ означает, что первичные ключи с несколькими столбцами должны иметь один индекс, охватывающий все столбцы. PostgreSQL создаст этот индекс автоматически, если вы объявите первичный ключ из нескольких столбцов.

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

Предположим, что любое изменение в индексировании улучшит некоторые действия базы данных и ухудшит другие. Я считаю полезным иметь набор операторов SQL, которые я могу профилировать до и после внесения изменений в индексы. Этот набор включает инструкции SELECT, INSERT, UPDATE и DELETE.

Там нет замены для изучения документов для ваших конкретных DBMS.

  • СОЗДАТЬ ИНДЕКС
  • Индексы (особенно обратите внимание на разделы по индексированию выражений, по частичным индексам и по изучению использования индексов)
Майк Шеррилл 'Cat Recall'
источник
14

В дополнение к тому, что @Catcall уже предоставлен , и добавим небольшую корректировку:

Я также рассмотрел некоторые основы в этом тесно связанном ответе на SO в последнее время .

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

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

Жирный акцент мой.

Вы можете хотеть , чтобы создать дополнительные индексы для второго или последующих столбцов индекса многоколоночного, но первый , как правило , покрыто только штраф индекса многоколоночного - кроме случаев , когда дополнительные колонки делают индекс намного больше. Мы обсудили это очень подробно под этим вопросом:

Составной индекс также хорош для запросов по первому полю?

Многоколоночные индексы , частичные индексы и индексы выражений являются особенно мощными инструментами в PostgreSQL. Начиная с PostgreSQL 9.2, также есть сканирование только по индексу , что эквивалентно «покрывающим индексам» в других RDBMS. Это не другой тип индекса, а новая возможность СУБД с существующими типами индекса.

Каждый индекс несет определенные затраты , поэтому нет никаких базовых знаний, чтобы действительно оптимизировать индексацию. Просто создание большего количества индексов может принести больше вреда, чем пользы. В частности, индексы могут препятствовать повышению производительности обновлений HOT .

Как правило, операции записи ( DELETE, UPDATE) становятся более дорогими (но также могут приносить пользу!), Тогда как операции чтения ( SELECT) обычно приносят пользу. Слишком много индексов может исчерпать кэш-память, так что даже операции чтения могут страдать.

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

Эрвин Брандштеттер
источник
Если я правильно помню, автоматический индекс поверх PK также создается в Oracle v.> = 10 и Sql Server> = 2008
EAmez
1

Есть два варианта.

  1. Ты делаешь это.
  2. Технология делает это.

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

Pghero

Pghero может помочь вам, если вам нужна автоматическая консультация.

Тем не менее, у него есть некоторые недостатки.

  1. Это работает только на WHEREи ORDER BY, нет JOINS.
  2. Он использует только статистику по проценту NULL и отдельным значениям.

Проверьте это видео для получения дополнительной информации .

Эван Кэрролл
источник