Каковы некоторые рекомендации и практические правила для создания индексов базы данных?

Question

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

Я добавил несколько базовых индексов btree на пару полей, и, как и следовало ожидать, производительность операций SQL существенно возросла. Желая получить максимальную производительность от dbms, я хочу сделать более взвешенный выбор того, что я должен индексировать во всех моих проектах.

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

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

Answer 1

Некоторые из моих эмпирических правил:

• Индексировать ВСЕ первичные ключи (я думаю, что большинство СУБД делают это при создании таблицы).
• Индексировать ВСЕ столбцы внешних ключей.
• Создайте больше индексов ТОЛЬКО если:
  • Запросы медленные.
  • Вы знаете, что объем данных значительно увеличится.
• Запуск статистики при заполнении большого количества данных в таблицах.

Если запрос медленный, найдите план выполнения и:

• Если запрос для таблицы использует только несколько столбцов, помещая все эти столбцы в индекс, вы можете помочь СУБД использовать только индекс.
• Не тратьте ресурсы на индексацию крошечных таблиц (сотни записей).
• Индексируйте несколько столбцов в порядке от высокого количества элементов к меньшему. Это означает, что сначала столбцы с более различными значениями, а затем столбцы с меньшим количеством различных значений.
• Если для запроса требуется доступ к более чем 10% данных, обычно полное сканирование лучше, чем индекс.

Answer 2

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

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

Answer 3

Как упоминал @David Aldridge, большинство баз данных выполняет намного больше операций чтения, чем записи, и, кроме того, соответствующие индексы часто используются даже при выполнении INSERTS (чтобы определить правильное место для INSERT).

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

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

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

Также убедитесь, что план планового обслуживания индекса также создан.