Индекс и операции вставки - PullRequest
Новая
       9

Индекс и операции вставки

2 голосов
/ 14 ноября 2009

У меня есть одна работа с около 100K записей для обработки. Это задание усекает таблицы назначения, а затем вставляет в эти таблицы все записи «по одной», а не пакетную вставку.

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

Существуют ли лучшие практики или советы по оптимизации в такой ситуации?

Ответы [ 3 ]

3 голосов
/ 14 ноября 2009

На этот тип вопроса можно ответить только в индивидуальном порядке . Однако следующие общие соображения могут быть полезны:

  • Если только некоторые данные для вставок не получены из дополнительных поисков и т. Д., Индекс не используется во время INSERT (т. Е. Для этой самой операции индексы, конечно, могут быть полезны для других запросов в других сеансах / пользователях ....)
  • [с другой стороны ...] Наличие индексов в таблице замедляет операции INSERT (или, в более общем случае, UPDATE или DELETE)
  • Порядок добавления новых записей может иметь значение
  • Особое внимание следует уделить, если таблица является кластерным индексом
  • Решение о том, удалять ли индексы (все или некоторые из них) перед операцией INSERT, во многом зависит от относительного количества записей (добавленных и готовых к вводу)
  • Операции INSERT могут часто приводить к фрагментации индекса, что само по себе является дополнительным стимулом для того, чтобы отбросить индексы перед загрузкой данных, а затем перестроить их (*).

Как правило, добавление 100 000 записей является «маленьким картофелем» для MS-SQL, и, за исключением особых ситуаций, таких как необычно широкие записи или наличие множества (и, возможно, плохо определенных) ограничений различного характера, SQL Server следует обрабатывать эту нагрузку в считанные минуты, а не часы на большинстве аппаратных конфигураций.

1 голос
/ 14 ноября 2009

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

Некластеризованные индексы не имеют этой проблемы; все, что нужно сделать серверу, это отслеживать, где хранится новая запись. Таким образом, если ваш индекс кластеризован (большинство кластеризованных индексов являются первичными ключами, но это не обязательно; запустите sp_helpindex [TABLENAME] ", чтобы убедиться в этом), вам почти наверняка будет лучше добавить индекс после того, как все ваши вставки будут сделано.

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

Редактирование: Поскольку вы можете позволить себе урезать всю таблицу с точки зрения производительности, вам почти наверняка лучше отбросить (или NOCHECKing) свои индексы и ограничения перед выполнением всех вставок, а затем добавить их обратно в конец.

0 голосов
/ 14 октября 2013

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

Чем больше таблица индексов, тем медленнее становится выполнение.

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

Проверьте здесь

...