Улучшение производительности Sql Удаляет

Я задаюсь вопросом, если парсинг В пункте с 70K объектами в нем является проблемой. Вы попробовали временную таблицу соединением вместо этого?

Существует два способа заставить операторы как этот работать:

1. Составьте новую таблицу и скопируйте все кроме строк для удаления. Подкачайте таблицы впоследствии (alter table name ...) Я предлагаю дать ему попытку, даже когда это звучит глупым. Некоторые базы данных намного быстрее при копировании, чем при удалении.

2. Разделите свои таблицы. Составьте таблицы N и используйте представление для присоединения к ним в одного. Отсортируйте строки в различные таблицы, сгруппированные удалить критерием. Идея состоит в том, чтобы отбросить целую таблицу вместо того, чтобы удалить отдельные строки.

Sybase может обработать 70K аргументы в В пункте? Все базы данных, с которыми я работал, имеют некоторый предел на количество аргументов в пользу IN пункт. Например, Oracle имеют предел приблизительно 1 000.

Можно ли создать подвыбор вместо В пункте? Это сократит sql. Возможно, это могло помочь для такого большого количества значений в В пункте. Что-то вроде этого:

  DELETE FROM OUR_TABLE WHERE ID IN 
        (SELECT ID FROM somewhere WHERE some_condition)

Удаление большого количества записей может быть ускорено с некоторыми вмешательствами в базу данных, если модель базы данных разрешает. Вот некоторые стратегии:

1. можно ускорить вещи путем отбрасывания индексов, удаления записей и воссоздания индексов снова. Это устранит изменяющие баланс индексные деревья при удалении записей.

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

   • отключите включает таблицу, если у Вас есть кто-либо и если Ваши бизнес-правила позволяют это. Удалите записи, затем включите триггеры.

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

Я попробовал бы комбинацию 1, 2 и 3. Если это не работает, то 4. Если бы все медленно, я искал бы большее поле - больше памяти, более быстрые диски.

our_table имеет ссылку на, удаляют каскад?

Узнайте то, что израсходовало производительность!

Во многих случаях Вы могли бы использовать одно из предоставленных решений. Но могли бы быть другие (на основе знания Oracle, таким образом, вещи будут отличаться на других базах данных.Править: просто видел, что Вы упомянули sybase):

• У Вас есть внешние ключи на той таблице? Удостоверяется, что относящиеся идентификаторы индексируются
• У Вас есть индексы на той таблице? Это могло бы быть это отбрасывающее, прежде чем удалят и воссоздающий после того, как удаление могло бы быть быстрее.
• проверьте план выполнения. Это использует индекс, где полное сканирование таблицы могло бы быть быстрее? Или наоборот? ПОДСКАЗКИ могли бы помочь
• вместо выбора в new_table, как предложено выше составлять таблицы, поскольку выбор мог бы быть еще быстрее.

Но помните: Узнайте то, что израсходовало производительность сначала.

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

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

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

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