Сколько индексов базы данных слишком много?

Question

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

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

Пространство не вызывает беспокойства; у нас есть 4-терабайтный RAID-привод, из которого мы используем только небольшую долю. Тем не менее, я беспокоюсь о возможных штрафах за производительность за счет слишком большого количества индексов. Поскольку эти индексы необходимо обновлять каждый раз, когда строка добавляется, удаляется или модифицируется, я полагаю, что было бы плохой идеей иметь десятки индексов на одной таблице.

Итак, сколько индексов считается слишком большим? 10? 25? 50? Или я должен просто накрыть действительно, действительно общие и очевидные случаи и игнорировать все остальное?

Answer 1

Это зависит от операций, которые происходят на столе.

Если есть много SELECT и очень мало изменений, укажите все, что вам нравится .... они (потенциально) ускорят высказывания SELECT.

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

Сказав, что , вы можете явно добавить много бессмысленных указателей в таблицу, которая ничего не сделает. Добавление индексов B-Tree в столбец с двумя разными значениями будет бессмысленным, поскольку оно не добавляет ничего с точки зрения поиска данных. Чем уникальнее значения в столбце, тем больше он будет пользоваться индексом.

Answer 2

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

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

Теперь, если ваше приложение имеет достаточный объем чтения или даже более того, если оно почти все читается, то индексы - это путь, так как будут значительные улучшения производительности при очень низкой стоимости.

Answer 3

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

Answer 4

Сколько столбцов существует? Мне всегда говорили делать индексы с одним столбцом, а не с несколькими столбцами. Так что больше индексов, чем количество столбцов, ИМХО.

Answer 5

Одна вещь, которую вы можете рассмотреть, - это создание индексов для таргетинга на стандартную комбинацию поисков. Если обычно используется столбец1, и с ним часто используется столбец2, а column3 иногда используется с столбцом2 и столбцом1, то индекс для столбца1, столбца2 и столбца3 в этом порядке может использоваться для любого из этих трех обстоятельств, хотя это только один индекс, который необходимо сохранить.

Answer 6

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

Любой индекс, который не соответствует этим критериям, будет стоить вам больше средств для восстановления, чем штраф за исполнение, если не иметь его в нечетном случае, который он использовал.

Answer 7

В парафразе Einstein о простоте добавьте столько индексов, сколько вам нужно, и не более.

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

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

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

Answer 8

На мой взгляд, нет статического ответа, такого рода вещи подпадают под «настройку производительности».

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

Помимо просто индексирования, вы можете перевернуть вашу БД, чтобы включить рассчитанные поля поиска, разбиение таблиц и т. Д. - это действительно зависит от ваших форм нагрузки и параметров запроса, сколько/каких данных «действительно» нужно перенаправить по запросу.

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

Для SQL Server я нашел советника по настройке ядра базы данных полезным - вы настроили «типичные» рабочие нагрузки и можете давать рекомендации по добавлению/удалению индексов и статистики. Я уверен, что у других БД есть аналогичные инструменты - «официальные» или сторонние.

Answer 9

Это действительно более теоретические вопросы, чем практические. Влияние индексов на вашу производительность зависит от оборудования, которое у вас есть, от версии Oracle, типов индексов и т. Д. Вчера я слышал, что Oracle анонсировала выделенное хранилище HP, которое должно выполнять в 10 раз быстрее с базой данных 11g. Что касается вашего случая, может быть несколько решений: 1. Имейте большое количество индексов (> 20) и перестраивайте их ежедневно (в ночное время). Это было бы особенно полезно, если таблица ежедневно получает тысячи обновлений/удалений. 2. Разделите свою таблицу (если это применит ваша модель данных). 3. Используйте отдельную таблицу для новых/обновленных данных и выполните ночной процесс, который объединяет данные. Это потребует изменения в вашей логике приложения. 4. Перейдите на IOT (индекс организованной таблицы), если ваши данные поддерживают это.

Конечно, может быть много решений для такого случая. Мое первое предложение для вас состояло в том, чтобы клонировать БД в среду разработки и выполнять некоторые стресс-тесты против него.

Answer 10

Обычно я продолжаю так.

1. Получить журнал из реальных запросов, выполняемых на данных в обычный день.
2. Добавьте индексы, чтобы наиболее важные запросы попадали в индексы в плане выполнения.
3. Попытайтесь избежать индексирования полей, которые содержат много обновлений или вставок
4. После нескольких индексов получите новый журнал и повторите.

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

Answer 11

Индекс налагает затраты при обновлении базовой таблицы. Индекс дает преимущество, когда он используется для ускорения запроса. Для каждого индекса вам необходимо сопоставить стоимость с выгодой. Насколько медленнее выполняется запрос без индекса? Сколько выгоды работает быстрее? Можете ли вы или ваши пользователи терпеть медленную скорость, когда индекс отсутствует?

Можете ли вы допустить дополнительное время, необходимое для завершения обновления?

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

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

Answer 12

В хранилище данных очень часто бывает большое количество индексов. Я работал с таблицами фактов, имеющими две сотни столбцов и 190 из них проиндексированы.

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

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

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

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

Answer 13

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

alter index my_index_name monitoring usage; 

Вы можете контролировать, является ли индекс, используемый или не с этого момента, запрашивая v $ object_usage.Информацию об этом можно найти в Oracle® Database Administrator's Guide.

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

Answer 14

В дополнение к точкам, которые все остальные подняли, Оптимизатор затрат на затраты несет затраты при создании плана для оператора SQL, если есть больше индексов, потому что для этого есть больше комбинаций. Вы можете уменьшить это, правильно используя переменные связывания, чтобы операторы SQL сохранялись в кеше SQL. Затем Oracle может выполнить мягкий анализ и повторно использовать план, который он нашел в прошлый раз.

Как всегда, ничего не происходит. Если есть искаженные столбцы и гистограммы, это может быть плохой идеей.

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

Answer 15

Я провел несколько простых тестов в своем реальном проекте и в реальной базе данных MySql. Я уже отвечал в этой теме: What is the cost of indexing multiple db columns?

Но я думаю, что это будет лучше, если я процитирую его здесь:

Я сделал несколько простых тестов, используя свой реальный проект и реальную базу данных MySql.

Мои результаты: добавление среднего индекса (1-3 столбца в индексе) к таблице - делает вставки медленнее на 2,1%. Итак, если вы добавите 20 индексов, ваши вставки будут быть медленнее на 40-50%. Но ваш выбор будет в 10-100 раз быстрее.

Итак, можно добавить много индексов? - Это зависит :) Я дал вам свои результаты - вы решите!

Answer 16

Sql-сервер дает вам хорошие инструменты, которые позволяют вам видеть, какие индексы используются на самом деле. Эта статья, http://www.mssqltips.com/tip.asp?tip=1239, дает вам несколько запросов, которые позволяют лучше понять, насколько используется индекс, а не насколько он обновляется.

Answer 17

Он полностью основан на столбцах, которые используются в разделе Where Where. И как «Правило большого пальца», у нас должны быть индексы на внешних колонках ключей, чтобы избежать DEADLOCKS. Отчет AWR должен анализировать периодически, чтобы понять необходимость индексов.