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

Я обычно так делаю.

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

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

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

alter index my_index_name monitoring usage;

Затем вы можете проверить, используется ли индекс с этой точки вперед, запросив v $object_usage. Информацию об этом можно найти в Руководство администратора базы данных Oracle.

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

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

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

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

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

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

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

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

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

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

Я сделал несколько простых тестов в своем реальном проекте и в реальной базе данных MySql. Я уже ответил в этой теме: Какова стоимость индексации нескольких столбцов db?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сколько столбцов есть? Мне всегда говорили делать индексы с одним столбцом, а не с несколькими столбцами. Таким образом, не больше индексов, чем количество столбцов, IMHO.

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