Оператор обновления работает слишком долго или нет

Question

Я новичок в работе с таким большим количеством данных (20 миллионов строк), и я не знаю, чего ожидать от продолжительности запроса:

update table set field = '1234'  

Нет индекса для поляЭто заявление заняло 25 минут.База данных настроена на простое восстановление.25 минут кажутся слишком длинными?Таблица имеет 9 столбцов с небольшими типами данных <50 varchar. </p>

Answer 1

Если вы обновили 20M строк в одной транзакции, тогда ваше время полностью зависело от вашей подсистемы ввода-вывода: какие у вас диски, какая структура файлов на диске и т. Д. Если у вас 40 шпинделей в raid 10 с 4 сбалансированными файлами и отдельная аналогичная батарея для бревна, тогда результат мучительно медленный. Если вы проверили это с одним MDF, который разделяет шпиндель с LDF на одном жестком диске с качеством 5000 об / мин, то ваше время будет удивительно быстрым.

Answer 2

Вы обновляете 20 записей Mio за 1500 с, в среднем со скоростью 7000 обновлений в секунду.Звучит примерно так.

Answer 3

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

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

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