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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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