Когда 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;