Оператор обновления выполняется слишком долго или нет
Я новичок в работе с таким большим количеством данных (20 миллионов строк), и я не знаю, чего ожидать от длительности запроса:
update table set field = '1234'
Нет индекса по полю. Это заявление заняло 25 минут. База данных настроена на простое восстановление. 25 минут кажутся слишком длинными? В таблице 9 столбцов с небольшими типами данных <50 varchar.
3 ответа
ЕСЛИ вы обновили 20 миллионов строк за одну транзакцию, тогда ваше время полностью зависело от вашей подсистемы ввода-вывода: какие у вас диски, какая структура файлов на диске и т. Д. Если у вас 40 шпинделей внутри raid 10 с 4 сбалансированными файлами и отдельной аналогичной батареей для журнала, результат очень медленный. Если вы протестировали это с одним MDF, который делит шпиндель с LDF на одном жестком диске потребительского качества 5000 об / мин, то ваше время удивительно быстро.
Вы обновляете 20 миллионов записей примерно за 1500 секунд со средней скоростью примерно 7000 обновлений в секунду. Звучит примерно правильно.
- Есть ли какие-либо проиндексированные представления, ссылающиеся на это поле?
- Публикуется ли это поле в (транзакционной) схеме репликации?
- Обращаются ли другие сеансы к этой таблице одновременно с обновлением. работает?
- Хранятся ли файлы журнала и данных на разных дисках (физических, а не в двух разных разделах одного и того же оборудования)?
- Существуют ли какие-либо ограничения проверки, ссылающиеся на это поле?
- Есть ли какие-либо триггеры в этой таблице ?
Все эти и, вероятно, многие другие факторы повлияют на производительность модификации данных.
В противном случае попробуйте выполнить пакетное обновление, используя TOP и предложение WHERE , которое находит только не измененные строки.