Удалите записи SQL Server 2005 без входа

Вы удаляете данные, но у вас есть предложение where, поэтому применяются обычные рекомендации по производительности для SQL.

Использовали ли вы профилировщик SQL для просмотра плана выполнения запросов? Если вы записываете эти операции, вы можете использовать мастер производительности, чтобы проанализировать их и, возможно, предложить новый индекс.

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

Если вы удаляете всю таблицу, вы можете использовать TRUNCATE TABLE, который регистрирует только удаление страниц, а не запись для каждой удаленной строки. Мне неизвестен способ удаления без регистрации транзакций.

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

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

1) Есть ли у вас какие-либо триггеры DELETE, которые срабатывают на ваших столах? Если так, то это могло быть источником медлительности.

2) Правильно ли настроил ваш администратор базы данных базу данных, как минимум, сохраняя журнал транзакций и файлы данных на отдельных физических дисках?

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

4) У вас слишком много индексов или слишком большая нагрузка на индексирование таблицы, из которой вы удаляете? Каждая удаленная строка будет соответствовать записи в каждом удаляемом индексе, поэтому будьте осторожны при использовании индексов. Поддерживаются ли ваши индексы должным образом?

5) Долго ли занимает поиск строк, которые вы хотите удалить? Если предложение WHERE в вашем операторе DELETE слишком затратно, это действительно замедлит ваши удаления. Попробуйте временно заменить оператор DELETE оператором SELECT и посмотреть, быстро ли выполняется этот запрос. Если это не так, вам следует оптимизировать оператор SELECT, отредактировав его, реструктурируя таблицы или добавив соответствующие индексы. Затем измените оператор обратно на DELETE. Производительность должна быть значительно улучшена, если выполнение соответствующего оператора SELECT улучшилось во время оптимизации.

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

Забудьте о транзакции log в качестве источника скорости или чего-либо другого, кроме того, что используется внутри БД для обеспечения согласованности. Вместо этого вам следует подумать о том, чтобы найти способ выполнять удаление партиями. Вместо одного оператора удаления, и если у вас есть целочисленный PK в таблице, попробуйте удалить диапазоны значений и сделайте это в цикле. Что-то вроде

Declare @RecordsLeft int
Declare @StartRange int
Declare @EndRange int
Declare @BatchSize int

Set @BatchSize = 10000
Set @RecordsLeft = ( Select Count(*) From ... )
Set @StartRange = 0
Set @EndRange = @StartRange + @BatchSize

While @RecordsLeft > 0
Begin
    Delete ...
    Where ...
      And PK Between @StartRange And @EndRange

    Set @RecordsLeft = ( Select Count(*) From ... )
    Set @StartRange = @EndRange + 1
    Set @EndRange = @StartRange + @BatchSize
End

Прежде всего, обратите внимание, что вы не можете НЕ иметь журнал транзакций... что если вы потеряете питание на сервере во время выполнения огромного удаления? Эта информация необходима, чтобы SQL Server мог выполнять атомарные операции...

Что вас может заинтересовать, так это "модель восстановления". Пожалуйста, прочитайте эту статью на technet: http://technet.microsoft.com/en-us/library/ms189275.aspx