Оптимизация удаляет на SQL Server

Начиная с C # 2.0, вы можете использовать универсальный тип Nullable Nullable, а в C # есть условное обозначение типа, за которым следует?

, например

private void Example(int? arg1, int? arg2)
{
    if(arg1 == null)
    {
        //do something
    }
    if(arg2 == null)
    {
        //do something else
    }
}
41
задан bummi 21 November 2014 в 00:08
поделиться

12 ответов

Следующая статья, Операции быстрого упорядоченного удаления могут вас заинтересовать.

Выполнение операций быстрого удаления SQL Server

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

22
ответ дан 27 November 2019 в 00:34
поделиться

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

Команда SQLCAT использовала этот метод для действительно действительно больших объемов данных. Я нашел несколько ссылок на него здесь , но я постараюсь найти что-нибудь более определенное.

2
ответ дан 27 November 2019 в 00:34
поделиться

Я добавлю к этому еще одно:

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

2
ответ дан 27 November 2019 в 00:34
поделиться

(если индексы «не используются», зачем они вообще?)

Один из вариантов, который я использовал в прошлом, - выполнять работу пакетами. Грубым способом было бы использовать SET ROWCOUNT 20000 (или что-то еще) и цикл (возможно, с WAITFOR DELAY ), пока вы не избавитесь от всего этого (@@ ROWCOUNT = 0).

Это может помочь уменьшить влияние на другие системы.

4
ответ дан 27 November 2019 в 00:34
поделиться

У меня гораздо больше опыта работы с Oracle, но, скорее всего, то же самое относится и к SQL Server:

  • при удалении большого количества строк блокируйте таблицу, чтобы база данных не придется выполнять множество блокировок строк
  • , если на таблицу, из которой вы удаляете, ссылаются другие таблицы,убедитесь, что эти другие таблицы имеют индексы в столбцах внешнего ключа (в противном случае база данных будет выполнять полное сканирование таблицы для каждой удаленной строки в другой таблице, чтобы убедиться, что удаление строки не нарушает ограничение внешнего ключа)
15
ответ дан 27 November 2019 в 00:34
поделиться

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

Мои предложения:

  • Убедитесь, что таблица имеет первичный ключ и кластерный индекс (это жизненно важно для всех операций).
  • Убедитесь, что кластеризованный индекс таков, что при удалении большого блока строк произойдет минимальная реорганизация страницы.
  • Убедитесь, что критерии выбора соответствуют поисковому запросу.
  • Убедитесь, что все ваши ограничения внешнего ключа в настоящее время являются доверенными.
5
ответ дан 27 November 2019 в 00:34
поделиться

Если верно, что ОБНОВЛЕНИЯ выполняются быстрее, чем УДАЛЕНИЯ, вы можете добавить столбец состояния с именем УДАЛЕННЫЙ и фильтровать его при выборе. Затем запустите на ночь процедуру, которая выполняет фактическое удаление.

1
ответ дан 27 November 2019 в 00:34
поделиться

Есть ли у вас внешние ключи с активированной ссылочной целостностью? У вас активны триггеры?

1
ответ дан 27 November 2019 в 00:34
поделиться

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

1
ответ дан 27 November 2019 в 00:34
поделиться

Проблема в том, что вы недостаточно определили свои условия. Т.е. что именно вы оптимизируете?

Например, не работает ли система для еженедельного обслуживания и в системе нет пользователей? И вы удаляете большой% базы данных?

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

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

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

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

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

4
ответ дан 27 November 2019 в 00:34
поделиться

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

10
ответ дан 27 November 2019 в 00:34
поделиться

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

Удалять партиями.

Если у вас есть таблицы внешних ключей, которые больше не используются (вы удивитесь, как часто производственные базы данных заканчиваются старыми таблицами, от которых никто не избавится), избавьтесь от них или, по крайней мере, разорвите соединение FK / PK. . Нет смысла проверять таблицу на наличие записей, если она не используется.

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

3
ответ дан 27 November 2019 в 00:34
поделиться
Другие вопросы по тегам:

Похожие вопросы: