Обновление TSQL для большой таблицы с другими из TEMPDB вызывает огромный рост

У меня есть пользовательский инструмент импорта, который массово вставляет данные в temp (421776 строк). После этого инструмент вставляет неизвестные строки в целевую таблицу и обновляет существующие строки на основе хеш-ключа (комбинация из 2 столбцов). Целевая БД имеет почти одинаковое количество строк. Запрос на обновление выглядит примерно так (примерно на 20 столбцов обновления)

  update targetTable set 
        theDB.dbo.targetTable.code=temp.code,
        theDB.dbo.targetTable.name=temp.name,
  from [tempDB].[dbo].[targettable] as temp 
  where theDB.dbo.targetTable.hash=temp.hash COLLATE SQL_Latin1_General_CP1_CI_AS

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

Просто примечание для тех, кто сталкивается с проблемами tempdb. Хорошее чтение: http://bradmcgehee.com/wp-content/uploads/presentations/Optimizing_tempdb_Performance_chicago.pdf

Источник

3 ответа

Решение

Похоже, вы явно используете tempdb с данными, которые вы там поместили. Есть ли причина использовать tempdb, как если бы это была ваша собственная база данных?

Причиной роста tempdb является то, что вы явно помещаете туда данные. 420k строк не звучат тяжело, но лучше держать их в пределах своей базы данных.

Предложите изменить свою бизнес-логику, чтобы отойти от [tempDB].[dbo].[targettable] к чему-то в вашей собственной базе данных пользователей.

Источник

Это декартово произведение, когда нет явного соединения?

Источник

Вы можете временно изменить ведение журнала транзакций с Полного или Массового входа в систему на простой. Это будет держать все от входа в систему для отката.

Источник
Другие вопросы по тегам