Индексация большой таблицы в SQL SERVER

Нам нужно увидеть ваши индексы, но, скорее всего, да.

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

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

Это классический инженерный компромисс ... вы можете сделать лопату легче или прочнее, но не то и другое вместе ... (до прорыва в материаловедении).

Больше индекса означает больше обслуживания DML, означает более быстрые запросы.

Меньшее количество индексов означает меньшее обслуживание DML, означает более медленные запросы.

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

Помимо того, что написал Джоэл, вам также необходимо определить SLA для DML. Это нормально, что он медленнее, вы заметили, что он замедлился, но действительно ли это имеет значение по сравнению с улучшением запросов, которое вы достигли ... IOW, можно ли иметь такую ​​слабую лопату?

Вы можете выбрать несколько решений

а) Вы можете разделить таблицу

б) Рассмотрите возможность выполнения пакетных обновлений в нерабочее время (например, ночью).

c) Поскольку разработка - это баланс компромиссов, вам нужно будет выбрать, что важнее (Выбрать или Обновить / вставить / удалить) и какая операция важнее. Предполагая, что вам не нужны результаты в реальном времени для «вставки», вы можете использовать сервисный брокер сервера Sql для этих операций, чтобы выполнять «менее важную» операцию асинхронно.

http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx

Спасибо -RVZ

Вы можете попробовать уменьшить количество разделений страниц (в ваших индексах), уменьшив коэффициент заполнения в ваших индексах. По умолчанию коэффициент заполнения равен 0 (соответствует 100 процентам). Итак, когда вы перестраиваете свои индексы, страницы полностью заполняются. Это отлично подходит для таблиц, которые не изменяются (вставка / обновление / удаление). Однако при изменении данных индексы должны измениться. При коэффициенте заполнения 0 вы гарантированно получите разделение страниц.

Изменив коэффициент заполнения, вы должны повысить производительность при вставках и обновлениях, потому что страница НЕ ВСЕГДА должна разделяться. Я рекомендую вам перестроить индексы с коэффициентом заполнения = 90. Это оставит 10% страницы пустыми, что приведет к меньшему разбиению страниц и, следовательно, к меньшему количеству операций ввода-вывода. Возможно, что 90 - не оптимальное значение для использования, поэтому здесь может быть задействован метод проб и ошибок.

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

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

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