Комментарии 7
Очень посредственный, явно машинный, перевод. Есть пара строк, которые вообще не переведены. Вы вообще вычитывали текст перед публикацией?
Странно, что не упомянут суммарный размер занимаемого места для индексов. Встречал таблицы, где размер индексов больше, чем сами данные в таблице (но индексы нужны, так что увы и ах).
Я понимаю, что это перевод, но всё-таки…
Достаточно странно оценивать накладные расходы на изменение индексов только количеством чтений. Не то, что оно не важно, но помимо него у нас добавляются операции записи и блокировки
Мои правила создания индексов и работы с ними (ни на что не претендую, просто делюсь):
Если таблица используется только на чтение, например это справочник - допустимо любое количество любых индексов.
Если это справочник, то кластерный индекс должен совпадать с полем, являющимся ключом справочника.
Если таблицы связаны через FK декларативной ссылочной целостностью, индекс по этому полю должен быть (но с учетом п.2)
Не стоит слепо доверять оптимизатору, который рисует зеленым подсказку про недостающий индекс. Во-первых, он может предложить индекс по слабоселективному полю, и индекс будет бесполезен, во-вторых, он может предложить синоним.
Перед тем, как создать индекс, обязательно нужно изучить все имеющиеся. Вдруг ты пытаешься создать синоним?
Обязательно нужно пользоваться административными представлениями, предоставляющими информацию о статистике использования индексов и статистике недостающих индексов. Но слепо верить им нельзя, т.к. и первое и второе дает адекватную информацию только на долго проработавшем сервере. Если ваш сервер каждую ночь перезагружается и не очень интенсивно используется - толку от ваших инструментов чуть.
Много индексов - зло. Мало индексов - зло втройне.
Если система, в любой ипостаси, предлагает сделать индекс по какому то полю, а в инклюд - все остальные поля это повод: а) посмотреть, а не стоит ли по этому полю сделать кластерный индекс или б) игнорировать эти вопли.
Не стоит стесняться использовать датабэйз энжин тюннинг адвизор. Особенно следующим способом: записать профайлером трек активности сервера за длительное время и скормить его адвизору. Но подходить к рекомендациям надо критически.
10 индексов на таблицу - это нормально. И 20. И 30. Зависит от того, что это за таблица и что это за система. Если это какая то витрина, olap (не куб, а просто база с данными для отчетов) - в создании индексов не ограничивает ничего. Ну будут данные заливаться не сутки, а трое, и что с того?
Кстати, отключить все индексы при заливке в хранилище, а потом включить их - позволяет сильно экономить время. Даже десятикратно иногда.
Бывают ситуации, когда даже один индекс - это чересчур много. Даже кластерный. И даже особенно кластерный.
Если вы делаете некластерные индексы на куче - это как минимум странно.
На быстро меняющихся таблицах, если у вас классическое oltp - индексы зло. И из зла надо выбирать меньшее по количеству, весу и большее по селективности.
Индексы стоит создавать даже в базах 1С. Не 1Совские, а sqlные, если вы понимаете о чем я. Но следить за ними надо вручную.
Индексы не нужно регулярно "обслуживать". Т.е. все эти ребилды и реорганайзы каждые сутки, пристальное слежение за фрагментацией - чушь собачья (чуть менее, чем всегда). Вот статистику нужно регулярно пересчитывать, и пристально следить за ее актуальностью, порогом обновления, если пересчет автоматический и т.д. Эффективность ребилда (не реорганайза) индексов происходит из того, что в процессе пересоздания индекса пересчитывается статистика.
Индексы нужно иногда обслуживать, потому что очень сильно фрагментированные большие индексы тупо не очень эффективно расходуют ОЗУ.
Покрывающие индексы - манна небесная.
Колоночные индексы - манна небесная вдвойне. Но использовать их, не поставив в известность разработчиков - не получится. Система, увидев, что на таблице есть (некластерный) колоночный индекс - будет стремиться использовать его, и скорость выполнения запросов волшебным образом сильно упадет. Чтобы этого не произошло, нужно прибить это стремление хинтом в запросах (которым поплохело).
Разработчиков, вообще, крайне желательно ставить в известность по поводу того, чего вы там накреативили с индексами. Ибо!
Не все проблемы с производительностью можно исправить индексами. И даже более того - только некоторые проблемы производительности можно исправить с помощью индексов. Разработчиков нужно приучать писать саргабельные запросы.
Если ваш запрос очень хорошо работает, и тут же - очень плохо работает, 99% дело не в индексе, и не стоит пытаться этот индекс "обслужить". Посмотрите, может дело в блокировках или банальном параметр-сниффинге. Вообще, активность разработчиков в стиле "а давайте перестроим индексы и всё заработает" - нужно пресекать на корню. Если к вам пришли с такой сентенцией - 100 пудов у них в коде говно.
Индексы - если не главный, то очень заметный инструмент по борьбе с дедлоками.
Индексы, наряду с декларативной ссылочной целостностью - главный источник дедлоков.
Поменьше фанатизма. Это к каждому пункту относится.
:-)
А есть ли какие инструменты для PostgreSQL, чтобы проанализировать индексы таблицы?
Индексы в базах данных: сколько индексов — перебор?