Производительность SQL Server: удаление / вставка и выбор / обновление

Question

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

В настоящее время мой псевдо-код выглядит так:

удалить из таблицы, где человек = 123 (удаляет около 200 строк)

Затем я заново вставляю обновленные данные (снова 200 строк). Данные всегда разные, так как они чувствительны ко времени.

Если бы я делал обновление вместо вставки, мне сначала пришлось бы выбрать строку (я использую ORM в c #).

ТЛ; др Мне просто интересно, простой вопрос, что является более экономически эффективным. Выбрать / Обновить или Удалить / Вставить?

Answer 1

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

2) Как бы вы справились с разницей в количестве элементов ОБНОВЛЕНИЯ? То есть. У человека = 123 есть 200 строк для удаления, но только 199 для вставки. Обновление не сможет справиться с этим.

Ваш лучший подход должен заключаться в использовании MERGE statemnent и табличного параметра с новыми значениями. Конечно, ни один ORM не может справиться с этим, но вы упомянули «производительность», и термины «производительность» и «ORM» нельзя использовать в одном предложении ...

Answer 2

С помощью кнопки «Удалить / Вставить» вы будете выполнять запись в базу данных дважды.Один раз удалить и один раз вставить.Вы также будете регистрировать обе эти транзакции по отдельности, если только вы не закроете весь процесс в одну транзакцию должным образом.

Вы можете протестировать оба метода и посмотреть результаты в SQL Profiler, но обновление 9/10 будетБыстрее.

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

Наконец, как говорит @MunduВы можете сделать это, используя параметризованный запрос через ADO.NET вместо ORM.