Начиная с C # 2.0, вы можете использовать универсальный тип Nullable Nullable, а в C # есть условное обозначение типа, за которым следует?
, например
private void Example(int? arg1, int? arg2)
{
if(arg1 == null)
{
//do something
}
if(arg2 == null)
{
//do something else
}
}
Следующая статья, Операции быстрого упорядоченного удаления могут вас заинтересовать.
Выполнение операций быстрого удаления SQL Server
Решение фокусируется на использовании представления для упрощения плана выполнения, созданного для операции пакетного удаления. Это достигается за счет обращения к данной таблице один раз, а не дважды, что, в свою очередь, снижает количество требуемых операций ввода-вывода.
В очень больших таблицах, где у вас есть очень специфический набор критериев для удаления, вы также можете разбить таблицу на разделы, отключить раздел, а затем обработать удаления.
Команда SQLCAT использовала этот метод для действительно действительно больших объемов данных. Я нашел несколько ссылок на него здесь , но я постараюсь найти что-нибудь более определенное.
Я добавлю к этому еще одно:
Убедитесь, что уровень изоляции транзакции и параметры базы данных установлены правильно. Если ваш SQL-сервер настроен на то, чтобы не использовать управление версиями строк, или вы используете уровень изоляции для других запросов, где вы будете ждать удаления строк, вы можете настроить себя на очень низкую производительность во время выполнения операции. .
(если индексы «не используются», зачем они вообще?)
Один из вариантов, который я использовал в прошлом, - выполнять работу пакетами. Грубым способом было бы использовать SET ROWCOUNT 20000
(или что-то еще) и цикл (возможно, с WAITFOR DELAY
), пока вы не избавитесь от всего этого (@@ ROWCOUNT = 0).
Это может помочь уменьшить влияние на другие системы.
У меня гораздо больше опыта работы с Oracle, но, скорее всего, то же самое относится и к SQL Server:
Если честно, удаление миллиона строк из таблицы масштабируется так же плохо, как вставка или обновление миллиона строк. Проблема в размере набора строк, и с этим мало что можно сделать.
Мои предложения:
Если верно, что ОБНОВЛЕНИЯ выполняются быстрее, чем УДАЛЕНИЯ, вы можете добавить столбец состояния с именем УДАЛЕННЫЙ и фильтровать его при выборе. Затем запустите на ночь процедуру, которая выполняет фактическое удаление.
Есть ли у вас внешние ключи с активированной ссылочной целостностью? У вас активны триггеры?
Есть удаления, затем есть удаления. Если вы удаляете устаревшие данные как часть задания обрезки, вы, надеюсь, сможете удалить смежные блоки строк по кластерному ключу. Если вам нужно удалить данные из таблицы большого объема, которая не является смежной, это очень болезненно.
Проблема в том, что вы недостаточно определили свои условия. Т.е. что именно вы оптимизируете?
Например, не работает ли система для еженедельного обслуживания и в системе нет пользователей? И вы удаляете большой% базы данных?
Если вы отключены от сети и удаляете большой%, возможно, имеет смысл просто создать новую таблицу с данными для хранения, удалить старую таблицу и переименовать. Если вы удаляете небольшой%, вы, вероятно, захотите объединить вещи настолько большими партиями, насколько позволяет место в журнале. Это полностью зависит от вашей базы данных, но удаление индексов на время перестройки может повредить или помочь - если даже возможно из-за того, что он находится в автономном режиме.
Если вы в сети, какова вероятность того, что ваши удаления конфликтуют с пользователем активность (и активность пользователей в основном читается, обновляется или что-то еще)? Или, вы пытаетесь оптимизировать работу пользователя или скорость выполнения вашего запроса? Если вы удаляете из таблицы, которая часто обновляется другими пользователями, вам необходимо выполнить пакетную обработку, но с меньшими размерами пакетов. Даже если вы сделаете что-то вроде блокировки таблицы для принудительной изоляции, это не принесет большой пользы, если ваш оператор удаления займет час.
Когда вы определите свои условия лучше, вы можете выбрать здесь один из других ответов. Мне нравится ссылка в сообщении Роба Сандерса для пакетирования вещей.
Когда вы определите свои условия лучше, вы можете выбрать здесь один из других ответов. Мне нравится ссылка в сообщении Роба Сандерса для пакетирования вещей.
Когда вы определите свои условия лучше, вы можете выбрать здесь один из других ответов. Мне нравится ссылка в сообщении Роба Сандерса для пакетирования вещей.
Интересно, пришло ли время для баз данных, собирающих мусор? Вы отмечаете строку для удаления, и сервер удаляет ее позже во время проверки. Вы бы не хотели, чтобы это происходило при каждом удалении, потому что иногда строка должна быть удалена сейчас, но иногда это может быть удобно.
Если у вас много таблиц внешних ключей, начните с конца цепочки и двигайтесь вверх. Окончательное удаление будет происходить быстрее и блокировать меньше вещей, если нет дочерних записей для каскадного удаления (что я бы НЕ включил, если бы у меня было большое количество дочерних таблиц, поскольку это убьет производительность).
Удалять партиями.
Если у вас есть таблицы внешних ключей, которые больше не используются (вы удивитесь, как часто производственные базы данных заканчиваются старыми таблицами, от которых никто не избавится), избавьтесь от них или, по крайней мере, разорвите соединение FK / PK. . Нет смысла проверять таблицу на наличие записей, если она не используется.
Не удалять - помечать записи как удаленные, а затем исключать отмеченные записи из всех запросов. Это лучше всего настроить во время проектирования базы данных. Многие люди используют это, потому что это также самый быстрый способ вернуть записи, случайно удаленные. Но это большая работа по настройке в уже существующей системе.