Когда MS-SQL поддерживает табличные индексы?

Question

Ради аргументов, скажем, для SQL 2005/8.Я понимаю, что когда вы помещаете индексы в таблицу для настройки SELECT операторов, эти индексы необходимо поддерживать во время действий INSERT / UPDATE / DELETE.

Мой главный вопрос таков:

Когда SQL Server будет поддерживать индексы таблицы?

У меня много последующих вопросов:

Я наивно полагаю, что это будет такпосле выполнения команды.Скажем, вы вставляете 20 строк, он будет поддерживать индекс после того, как 20 строк были вставлены и зафиксированы.

• Что происходит в ситуации, когда сценарий содержит несколько операторов для таблицы, нов противном случае отдельные операторы?

• Имеет ли сервер сведения для ведения индекса после выполнения всех операторов или он выполняет это для каждого оператора?

Я видел ситуации, когда индексы удалялись и создавались заново после больших / многих INSERT / UPDATE действий.

• Это, вероятно, влечет за собой перестройку индексов всей таблицы, даже если вы измените только несколько строк?

• Будет ли увеличение производительности при попыткеобъединить действия INSERT и UPDATE в более крупный пакет, скажем, собирая строки для вставки во временную таблицу, в отличие от множества меньших вставок?

• Как будет сопоставляться строки над стекомпротив понижения индекса против принятия обслуживания обслуживания?

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

Редактировать: Я понимаю, что вопросы производительности во многом зависят от объема данных при вставке / обновлении и количества индексов.Опять же, ради аргументов, у меня было бы две ситуации:

• Таблица индексов, настроенная для выбора.
• Таблица индексов (PK).

В обеих ситуациях будет большой пакет вставки / обновления, скажем, 10k + строк.

Редактировать 2: Мне известно, что я могу профилировать данный скрипт в наборе данных.Однако профилирование не говорит мне, почему данный подход быстрее другого.Меня больше интересует теория индексов и того, где возникают проблемы с производительностью, а не окончательный ответ «это быстрее, чем этот».

Спасибо.

Answer 1

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

Редактировать: под «целостностью» я подразумеваю следующее: после фиксации данные должны быть немедленно доступны любому.Если в этот момент индексы не обновляются, кто-то может получить неправильные результаты.

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

Редактировать: если вы вставляете / обновляете / удаляете пакеты строк в одном операторе, ваши индексы изменяются один раз для каждого оператора.Следующий скрипт демонстрирует, что:

CREATE TABLE dbo.Num(n INT NOT NULL PRIMARY KEY);
GO
INSERT INTO dbo.Num(n)
SELECT 0
UNION ALL
SELECT 1;
GO
-- 0 updates to 1, 1 updates to 0
UPDATE dbo.Num SET n = 1-n;
GO
-- doing it row by row would fail no matter how you do it
UPDATE dbo.Num SET n = 1-n WHERE n=0;
UPDATE dbo.Num SET n = 1-n WHERE n=1;