Раньше я попал в толпу очистки объектов с помощью фоновых серверных процессов, однако недавние проблемы с чрезмерным ростом файла журнала TempDB изменили мое мнение.Я не уверен, что так было всегда с каждой версией SQL Server, но после перехода на SQL 2016 и размещения дисков в массиве PureStorage SSD дела идут немного по-другому.Процессы обычно связаны с процессором, а не с вводом / выводом, и явное удаление временных объектов не приводит к проблемам с ростом журнала.Несмотря на то, что я не слишком углубился в вопрос о том, почему, я подозреваю, что это не похоже на сборку мусора в мире .NET, где он синхронен при явном вызове и асинхронен при передаче в систему.Это будет иметь значение, потому что явное удаление освободит хранилище в файле журнала и сделает его доступным при следующем резервном копировании журнала, тогда как, по-видимому, это не тот случай, когда объект явно не отбрасывается.В большинстве систем это, вероятно, не является большой проблемой, но в системе, поддерживающей большое количество ERP и витрины с большим количеством одновременных транзакций и интенсивным использованием TempDB, это оказало большое влияние.Что касается того, почему в первую очередь создавать объекты TempDB с объемом данных в большинстве запросов, это все равно будет перетекать в хранилище TempDB, поэтому обычно более эффективно создать объект с необходимыми индексами, а не позволитьСистема обрабатывает это автоматически.