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

Question

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

Есть ли способ улучшить это.

Заранее спасибо

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Спасибо -RVZ

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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