Большое количество запросов UPDATE замедляет страницу

Question

Я читаю и проверяю большие текстовые файлы фиксированной ширины (от 10 до 50 тысяч строк), которые отправляются через наш веб-сайт ASP.net (в кодировке VB.Net). Я делаю первоначальное сканирование файла, чтобы проверить основные проблемы (длина строки и т. Д.). Затем я импортирую каждую строку в таблицу MS SQL. Каждая строка БД в основном состоит из record_ID (первичное, автоинкрементное) и около 50 полей varchar.

После того, как вставка завершена, я запускаю функцию проверки файла, которая проверяет каждое поле в каждой строке на основе набора критериев (усеченная длина, числовая, проверка диапазона и т. Д.). Если он находит ошибку в каком-либо поле, он вставляет запись в таблицу «Ошибки», в которой есть error_ID, record_ID и сообщение об ошибке. Кроме того, если поле выходит из строя определенным образом, я должен сделать «сброс» в этом поле. Сброс может состоять из очистки всего поля или простой замены значения другим значением (например, замена строки новой, в которой удалены все нелегальные символы).

У меня есть тестовый файл на 5000 строк. Загрузка, первоначальная проверка и импорт занимает около 5-6 секунд. Подробная проверка ошибок и вставка в таблицу ошибок занимает около 5-8 секунд (в этом файле содержится около 1200 ошибок). Тем не менее, часть «Сброс» занимает около 40-45 секунд для 750 полей, которые необходимо сбросить. Когда я закомментирую функцию сброса (возврат немедленно без фактического вызова хранимого процесса UPDATE), процесс очень быстрый. После сброса настроек возврат страниц занимает 50 секунд.

Мой хранимый процесс UPDATE использует рекомендуемый код из http://sommarskog.se/dynamic_sql.html,, в результате чего вместо динамического SQL используется CASE:

UPDATE dbo.Records
SET    dbo.Records.file_ID = CASE @field_name WHEN 'file_ID' THEN @field_value ELSE file_ID END,
.
. (all 50 varchar field CASE statements here)
.
WHERE dbo.Records.record_ID = @record_ID

Есть ли какой-нибудь способ помочь мне в этом выступлении. Можно ли как-то сгруппировать все эти вызовы UPDATE в одну транзакцию? Должен ли я каким-то образом переделывать запрос UPDATE? Или просто 750+ ОБНОВЛЕНИЙ и все просто медленно (это четырехъядерный сервер с 8 ГБ оперативной памяти).

Любые предложения приветствуются.

Answer 1

Не делайте этого в sql; Исправьте данные в коде, а затем обновите.

Если у вас есть sql 2008, посмотрите параметры таблицы. Это позволяет передавать всю таблицу в качестве параметра в s'proc. Из их всего лишь один оператор вставки / обновления или слияния

Answer 2

Если ваш цикл по строкам и выполнение отдельных обновлений / вставок может быть очень дорогим ... Рассмотрите возможность использования SqlBulkCopy , которая может ускорить все ваши вставки. Точно так же вы можете создать DataSet , внести обновления в набор данных и затем отправить их все за один снимок через SqlDataAdapter .

Answer 3

Um. Почему вы вставляете числовые данные в поля VARCHAR, а затем пытаетесь выполнить числовые проверки для них? Это отвратительно.

Примените правильную типизацию данных и ограничения к вашей таблице, сделайте INSERT и посмотрите, не удалось ли это. SQL Server с радостью сообщит вам об ошибках.

Answer 4

Я полагаю, что вы делаете 50 заявлений по каждому обновлению. Похоже, это будет медленно.

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

Пример быстрого и грязного кода.

string [] queryList = { "UPDATE records SET col1 = {val} WHERE ID={key}",
                        "UPDATE records SET col2 = {val} WHERE ID={key}",
                        "UPDATE records SET col3 = {val} WHERE ID={key}",
                         ...
                        "UPDATE records SET col50 = {val} WHERE ID={key}"} 

Затем при вызове SQL вы просто выбираете элемент в массиве, соответствующий столбцу, который хотите обновить, и задаете значение и ключ для параметризованных элементов.

Полагаю, вы увидите значительное улучшение ... дайте мне знать, как это происходит.

Answer 5

Я бы попробовал изменить модель восстановления на простую и посмотреть на мои индексы. Кимберли Трипп провел сеанс, демонстрируя сценарий с улучшенной производительностью с использованием кучи.